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ABSTRACT 


A  new  method  is  presented  for  the  deductive  synthesis  of  computer  programs. 
The  method  takes  as  given  a  formal  specification  of  a  user's  problem.  The 
specification  is  allowed  to  be  incomplete  in  that  some  or  all  of  the  input  con- 
ditions may  be  omitted.  A  completed  specification  plus  a  computer  program  are 
produced  by  the  method.  Synthesis  involves  the  top-down  decomposition  of  the 
user's  problem  into  a  hierarchy  of  subproblems.  Solving  each  of  these  subprob- 
lems  results  in  the  synthesis  of  a  hierarchically  structured  program.  The  pro- 
gram is  guaranteed  to  satisfy  the  completed  specification  and  to  terminate  on 
all  legal  inputs. 

In  this  paper  we  present  a  framework  for  a  top-down  synthesis  process, 
explore  the  structure  of  a  class  of  divide  and  conquer  algorithms,  and  present  a 
method  for  the  top-down  synthesis  of  algorithms  in  this  class.  Detailed  deriva- 
tions of  four  sorting  algorithms  are  presented. 


1  The  work  reported  herein  was  supported  by  the  Foundation  Research  Program 
of  the  Naval  Postgraduate  School  with  funds  provided  by  the  Chief  of  Naval 
Research. 
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1.  Introduction 

Program  synthesis  is  the  task  of  automatically  constructing  a  computer  pro- 
gram from  a  description  of  the  problem  it  is  intended  to  solve.  Although  the 
prospect  of  a  program  synthesis  system  replacing  human  programmers  is  a  long  way 
off  there  are  several  near-term  benefits  to  research  on  such  systems.  First,  a 
program  synthesis  system  requires  considerable  amounts  of  knowledge  about  pro- 
gramming and  about  the  reasoning  processes  involved  in  synthesis.  Before  con- 
structing such  a  system  we  are  forced  to  formalize  our  knowledge,  seeking  a 
degree  of  explicitness  not  normally  required  by  human  programmers.  This  process 
can  lead  to  deep  insights  into  aspects  of  programming  which  were  only  loosely 
organized  and  intuitively  understood  previously.  Properly  formulated,  such 
knowledge  can  contribute  to  a  science  of  programming  useful  both  to  human  pro- 
grammers and  automated  programming  systems.  Second,  as  aspects  of  the  program- 
ming task  become  better  understood,  it  is  natural  to  mechanize  them,  making  it 
easier  for  human  programmers  to  do  their  job.  Thus,  we  expect  to  see  special- 
purpose  program  synthesizers  and  programming  aids  become  available  long  before 
the  advent  of  general -purpose  synthesizers. 

In  this  paper  we  outline  a  program  synthesis  system  and  provide  in  detail 
some  of  the  knowledge  about  programming  required  by  such  a  system.  Our  basic 
approach  to  program  synthesis  is  a  form  of  top-down  design  -  a  technique  well- 
known  in  software  engineering  circles  but  not  previously  formalized  to  the 
extent  that  it  could  be  automated.  Top-down  design  works  as  follows:  given  a 
description  of  a  problem  we  decompose  it  into  descriptions  of  subproblems  in 
such  a  way  that  solutions  for  the  subproblems  can  be  assembled  into  a  solution 
for  the  original  problem.  We  then  apply  top-down  design  to  each  of  the  subprob- 
lem  descriptions.  The  decomposition  process  terminates  in  primitive  problem 
descriptions  which  are  solved  directly,  without  decomposition  into  subproblems. 
A  solution  to  the  original  problem  is  then  formed  by  composing  solutions  to  sub- 
problems  according  to  the  structure  of  the  subproblem  hierarchy. 

One  of  the  principal  difficulties  in  top-down  design  is  knowing  how  to 
decompose  a  problem  into  subproblems.  At  present  general  knowledge  of  this  kind 
(see  for  example  [18])  is  intuitive  and  not  in  a  form  suitable  for  automation. 
Rather  than  attempt  to  formalize  this  general  knowledge  we  focus  on  special  ways 
to  decompose  a  problem.  In  particular  we  present  a  theory  concerning  the  struc- 
ture of  divide  and  conquer  algorithms  and  show  how  to  decompose  a  problem  with 
respect  to  that  structure. 


-3- 


The  principle  underlying  divide  and  conquer  algorithms  can  be  simply 
stated:  if  the  problem  posed  by  a  given  input  is  sufficiently  simple  we  solve  it 
directly,  otherwise  we  decompose  it  into  subproblems,  solve  the  subproblems, 
then  compose  the  resulting  solutions.  The  process  of  decomposing  the  input  prob- 
lem and  solving  the  subproblems  gives  rise  to  the  term  "divide  and  conquer" 
although  "decompose,  solve  and  compose"  would  be  more  accurate.  One  form  of 
divide  and  conquer  is  expressed  in  an  ad-hoc  language  in  Figure  1.  We  actually 
employ  a  more  general  schema  in  this  paper. 

The  reader  will  notice  that  the  divide  and  conquer  principle  and  top-down 
design  are  similar  in  nature.  Both  rely  on  a  collection  of  operators  for  decom- 
posing problems  into  subproblems.  These  operators  may  work  on  some  problems  but 
not  on  others.  In  top-down  design  processes  we  often  lack  knowledge  about 
which,  if  any,  of  the  alternative  operators  will  work  on  a  given  problem,  so  we 
must  try  each  operator  in  turn;  that  is,  we  search.  Divide  and  conquer  algo- 
rithms, in  contrast,  have  an  inexpensive  test  to  determine  which  operator 
applies  to  a  given  problem,  thus  they  do  not  rely  on  search.  We  use  the  term 
simple  divide  and  conquer  for  algorithms  which  have  only  a  single  decomposition 
operator. 

We  chose  to  explore  the  synthesis  of  divide  and  conquer  algorithms  for 
several  reasons: 

!_.  Structural  Simplicity  -  Divide  and  conquer  is  perhaps  the  simplest  program 


Divide_and_Conquer  (x)  =  if  Primitive  (x) 

then  Divide_and_Conquer  :=  Direct_Solution  (x) 
else  begin 

(x^^)  :=  Decompose  (x)  ; 

y^  :=  Divide_and_Conquer (Xi ) ; 

Y2   :=  Divide_and_Conquer (x2) ; 

Divide_and_Conquer  :=  Compose (y,,y 9) 

end 

Figure  1.  A  divide  and  conquer  program  schema 
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structuring  technique  which  does  not  appear  as  an  explicit  control  structure  in 
current  programming  languages.  Our  description  of  the  structure  of  divide  and 
conquer  algorithms  is  based  on  a  view  of  them  as  computational  homomorphisms 
between  algebras  on  their  input  and  output  domains.  Careful  choice  of  program- 
ming language  constructs  allows  us  to  express  divide  and  conquer  algorithms  con- 
cisely and  in  accord  with  their  essential  structure  as  a  computational  homomor- 
phism. 

2.  Computational  Efficiency  -  Often  algorithms  of  asymptotically  optimal  com- 
plexity arise  from  the  application  of  the  divide  and  conquer  principle  to  a 
problem.  Fast  approximate  algorithms  for  NP-hard  problems  frequently  are  based 
on  the  divide  and  conquer  principle. 

_3.  Ubiquity  in  Programming  Practice  -  Divide  and  conquer  algorithms  are  common 
in  programming,  especially  when  processing  structured  data  objects  such  as 
arrays,  lists,  and  trees.  Current  textbooks  on  the  design  of  algorithms  stan- 
dardly present  divide  and  conquer  as  a  fundamental  programming  technique  [1], 

The  basic  concepts  underlying  our  approach  to  program  synthesis  are 
presented  in  Section  2.  While  we  have  attempted  to  make  this  paper  self- 
contained,  some  knowledge  of  first-order  logic  and  automatic  theorem  proving 
techniques  is  presumed  in  Section  2.5.  A  system  for  top-down  program  synthesis 
is  outlined  in  Section  3  together  with  the  special  knowledge  needed  to  syn- 
thesize simple  divide  and  conquer  algorithms.  A  detailed  illustration  of  the 
synthesis  process  is  provided  in  Section  3.4  with  the  derivation  of  a  selection 
sort.  Less  detailed  but  complete  derivations  are  given  in  Section  4  of  three 
other  sorting  algorithms.  We  distribute  discussion  of  related  research  efforts 
and  historical  context  among  the  appropriate  sections. 
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2.  Basic  Concepts 

2.1  Specifications 

A  program  synthesis  system  requires  as  input  a  description  of  a  problem  to 
be  solved.  Specifications  are  a  precise  notation  for  describing  the  problem  we 
desire  to  solve  without  necessarily  indicating  how  to  solve  it.  For  example, 
the  problem  of  sorting  a  list  of  natural  numbers  is  may  be  specified  as  follows^ 

Sort:x  =  z  such  that  Bag:x=Bag:z  A  Ordered:z 
where  Sort:  LIST(]N)  ->  LIST(]N). 

Here  the  problem  is  named  Sort  which  is  a  function  from  lists  of  natural  numbers 
(denoted  LIST(]N))  to  lists  of  natural  numbers.  Naming  the  input  x  and  the  out- 
put z,  the  formula  Bag:x=Bag:z  A  Ordered:z,  called  the  output  condition, 
expresses  the  conditions  under  which  z  is  an  acceptable  output  with  respect  to 
input  x.  Here  Bag:x=Bag:y  asserts  that  the  multiset  (bag)  of  elements  in  the 
list  y  is  the  same  as  he  multiset  of  elements  in  x.  Ordered :y  is  a  predicate 
which  holds  exactly  when  the  elements  of  list  y  are  in  nondecreasing  order. 
Generally,  a  problem  specification  (or  simply  a  specification)  ||  has  the  form 

||:x  =  z  such  that  I:x  =>  0:<x,z> 
where  Jf:  D  -»  R. 

We  ambiguously  use  the  symbol  ||  to  denote  both  the  problem  and  its  specifica- 
tion. Here  the  input  and  output  domains  are  D  and  R  respectively.  The  input 
condition  expresses  any  properties  we  can  expect  of  inputs  to  the  desired  pro- 
gram. Inputs  satisfying  the  input  condition  will  be  called  legal  inputs.  If  an 
input  does  not  satisfy  the  input  condition  then  we  don't  care  what  output  the 
program  produces.  The  output  condition  0  expresses  the  properties  that  an  out- 
put object  should  satisfy.  Any  output  object  z  such  that  0:<x,z>  holds  will  be 
called  a  feasible  output  with  respect  to  input  x.  More  formally,  a  problem 
specification  (specification)  IT  is  a  4-tuple  <D,R,I,0>  where 

D  is  a  set  called  the  input  domain, 

R  is  a  set  called  the  output  domain, 

I  is  a  relation  on  D  called  the  input  condition,  and 

0  is  a  relation  on  DXR  called  the  output  condition. 


2 
We  use  the  notation  f:x  to  denote  the  result  of  applying  the  function  or 

program  f  to  argument  x. 
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The  intention  is  that  a  program  F  satisfies  a  problem  specification  ||  if  on 
each  legal  input  F  computes  feasible  output.  More  formally,  program  F  satisfies 
problem  specification  ||  =<D,R,I,0>  if 

Vx6D[I:x  =»  0:<x,F:x>]  (2.1.1) 

is  valid  in  a  suitable  first-order  theory.  We  say  ||  is  a  complete  specifica- 
tion  of  F  if  formula  (2.1.1)  is  valid,  otherwise  it  is  an  incomplete  specifica- 
tion.  Specification  J\   =  <D,R,I,0>  is  unsatisfiable  if 

Vx€D  Vz€R  [I:x  =>  ~0:<x,z>] 

is  valid.  In  words,  ||  is  unsatifiable  if  for  each  legal  input  there  is  no 
feasible  output. 

The  definition  of  "satisfies"  can  be  weakened  slightly  with  the  following 
ideas  in  mind.  For  several  reasons  we  may  not  know  what  the  input  condition  for 
a  problem  should  be.  Most  importantly,  the  input  conditions  under  which  the 
output  condition  can  be  satisfied  may  be  difficult  to  know  ahead  of  time.  That 
is,  the  class  of  inputs  for  which  there  exists  feasible  outputs  may  not  be  known 
or  easily  describeable.  Also,  within  the  computational  or  competence  limits  of 
a  synthesis  system  it  may  not  be  possible  to  find  a  program  which  works  on  all 
legal  inputs.  In  both  cases  we  would  like  the  synthesis  system  to  "do  the  best 
it  can"  and  yield  a  program  F  together  with  an  input  condition  under  which  F  is 
guaranteed  to  terminate  with  a  feasible  output.  These  considerations  lead  to 
the  following  definition:  Program  F  satisfies  specification  ||  =<D,R,I,0>  with 
derived  input  condition  I'  if 

VxGD  [I':x  A  I:x  =>  0:<x,F:x>] 

is  valid. 

Note  that  a  synthesis  system  employing  this  weaker  concept  of  satisfaction 
can  always  generate  a  correct  output;  if  the  given  problem  is  too  hard  it  can 
always  return  a  do-no thing  program  with  the  boolean  constant  FALSE  as  derived 
input  condition.  However,  as  we  shall  see,  this  concept  of  a  derived  input  con- 
dition plays  a  more  serious  and  integral  role  in  our  method  in  that  they  are 
used  to  construct  certain  predicates.  Of  course  the  synthesis  of  a  program 
involves  trying  to  make  the  derived  input  condition  as  weak  as  possible.   We 


-  A  suitable  first-order  theory  is  discussed  in  Section  2.5.  It  is  assumed 
in  this  paper  that  all  predicates  involved  in  a  specification  are  total. 
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„xso  note  that  a  system  based  on  this  definition  of  satisfaction  allows  the 
user  to  ignore  input  conditions  when  formulating  a  specification.  However, 
deriving  an  input  condition  may  require  considerable  computation  which  could  be 
saved  if  the  user  supplies  a  correct  or  nearly  correct  input  condition  ini- 
tially. 

As  an  example,  suppose  a  program  synthesis  system  is  given  the  specifica- 
tion 

Select :x  =  <a,z>  such  that  a_<Bag:z  A  Bag:x  =  Add:<a,Bag:z> 
where  Select:  LIST (]N)  -»  ]N  X  LIST(  ]N) . 

Here  we  wish  to  split  a  list  x  into  two  components,  a  number  a  and  a  list  z  such 
that  a  is  no  larger  than  any  element  of  z  and  the  collection  of  elements  in  x  is 
the  same  as  the  collection  of  elements  in  z  with  a  added.  This  specification  is 
incomplete  in  that  there  is  no  feasible  output  with  respect  to  legal  input  nil 
(nil  denotes  the  empty  list) .  Our  synthesis  method  would  return  a  satisfying 
program  (see  Section  3.5.2)  with  derived  input  condition  x^nil.  This  condition 
is  then  used  as  a  guard  on  the  invocation  of  Select. 


2.2  Target  Programming  Language 

We  will  express  algorithms  in  a  typed  functional  programming  language  FPL 
based  on  Backus'  FP  systems  [2].  In  a  functional  programming  language  programs 
are  viewed  as  a  hierarchy  of  functions.  Such  languages  come  equipped  with  a  set 
of  primitive  functions  and  a  set  of  combining  forms  which  are  used  to  create 
complex  functions  from  simpler  ones.  FPL  differs  from  the  FP-system  in  Backus' 
paper  by  allowing  data  types,  new  combining  forms  called  function  products  and 
nondeterministic  conditionals,  and  a  little  syntactic  sugar. 

An  FP-like  system  such  as  FPL  can  be  described  in  terms  of  the  following 
components : 

1.  a  set  of  data  types  and  a  set  of  data  objects 

2.  a  set  of  primitive  functions 

3.  an  operation  called  application 

4.  a  set  of  combining  forms 

5.  a  function  definition  mechanism. 
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Data  Types  and  Data  Objects 

The  data  types  of  interest  in  this  paper  are  Tti  (natural  numbers),  LIST(U) 
(linear  lists  of  natural  numbers),  and  B  (boolean  values  TRUE  and  FALSE).  The 
symbol  J_,  called  bottom  or  undefined,  is  a  data  object  and  any  elements  of  the 
preceeding  data  types  are  data  objects.  If  x1,...,xn  for  n^>  0  are  data  objects 
then  the  n-tuple  <x-i,...,xn>  is  also  a  data  object.  If  some  object  in  a  n-tuple 
is  _|_  then  the  n-tuple  is  J_;  i.e.,  <..  .,J_, . .  .>  =_|_.  For  the  purposes  of  specify- 
ing, discussing,  and  reasoning  about  programs  we  extend  the  usual  equality  rela- 
tion so  that  it  is  defined  when  one  of  its  arguments  is  J_.  The  function 
Defined :x  will  be  used  to  distinguish  _|_  from  other  objects.  For  example, 
Defined :1  =  FALSE,  Defined  :<1, 3, 5>  =  TRUE. 

Application 

The  application  of  a  function  f  to  an  object  x,  written  f :x,  denotes  the 
object  which  results  from  applying  f  to  x. 

Functions 

All  functions  map  a  data  object  to  a  data  object.  If  a  function  requires  n 
arguments  for  some  n>_0,  then  it  is  applied  to  an  n-tuple  of  objects.  Simi- 
larly, if  a  function  generates  m  outputs  it  returns  an  m-tuple  of  objects. 
Functions  in  the  system  are  either  primitive  (supplied  with  the  system)  or  func- 
tional forms  (created  from  other  functions  by  means  of  combining  forms) .   The 
primitive  functions  of  FPL  are  listed  below  in  Figure  2  according  to  data  type. 
For  the  natural  numbers  we  have  the  usual  addition  function,  denoted  +,  the  com- 
parison functions  <,_<,  =  ,  ^  ,  ^>  ,>,  and  the  identity  function,  denoted  Id.  On 
the  data  type  LIST(]N)  we  use  the  functions  First,  which  returns  the  first  ele- 
ment in  a  list,  Rest,  which  returns  its  input  list  minus  the  first  element, 
Cons,  which  adds  a  number  to  the  front  of  a  list,  Append,  which  concatenates  two 
lists,  Length,  which  returns  the  length  of  a  list,  and  the  identity  function, 
denoted  Id.  Not  included  in  the  table  are  the  selector  functions  1,  2,  etc. 
defined  on  tuples.  For  example,  2:<3,  (1,2,3)  ,5>  =  (1,2,3) ,  2:<1>=_L.  All  func- 
tions in  FPL  are  l-preserving  in  that  f  :_|_  =  _|_  holds  for  each  function  in  the  sys- 
tem. 

Combining  Forms 

Combining  forms  are  used  to  create  a  new  function  from  other  functions. 
The  following  four  combining  forms  will  be  used: 
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1.  B  (Boolean) 

2.  IN  (natural  numbers) 

functions: 


example  values:  TRUE, FALSE 
example  values:  0,  1,  2,... 

name  examples 

+  +:<3,5>  =  8 

<'<'='  >  '>' ?       <:<3,5>=TRUE 
^  :<3,5>  =  false 

Id   (identity)   Id:3  =  3 


3.  LIST(]N)  (Lists  of  Natural  Numbers)    example  values:  nil  =  () ,  (1/2),  (4) 


name 
functions:    First 

Rest 

Cons 

Append 
Length 

Id 


example 

First:  (2,5,3)  =  2 

First:  ()  =1 

Rest:  (2,5,3)  =  (5,3) 

Rest:nil  =J_ 

Cons:<2,  (5,3)>=  (2,5,3) 

Cons:<2,nil>  =  (2) 

Append:<(2,4),(5,3,2)>  =  (2,4,5,3,2) 

Length:  (2,4,5,3)  =  4 

Length:nil  =  0 

Id:  (2,4,5,3)  =  (2,4,5,3) 


Figure  2.     Data  Types  and  Primitive  Functions  in  FPL 


1.  Composition  -  The  composition  of  functions  f  and  g  is  written  f  *g  and  is 
computed  by  first  applying  g  to  the  data  object  then  applying  f  to  the  result, 
so  for  all  data  objects  x     (f  *g)  :x  =  f :  (g:x) . 

For  example:     Length-Rest:  (1,3,5)   =  Length:  (Rest:  (1,3,5) ) 

=  Length:  (3,5) 
=  2 

2,  Construction  -  If  f^,...,fn  are  functions  and  x  a  data  object  then  the  con- 
struction of  these  functions  is  written  [f ,,...,  fn]  and  is  defined  by 
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[JL-i  f  m   •  •  /  L  _  J  •  X  —  ^^"1  •  X  /  •  •  •  §  L  p.  •  X  y   • 

For  example:   [First, Rest] :  (1,3,5)  =  <1,(3,5)> 

3.  Product  -  The  product  of  unary  functions  £p...ffn,  written  f  j^  X  •  ••  X  fn,  is 
defined  by 

f  i  X  •  •  •  X  £p  •  'Xw  • .  •  /X_>  =  <r  i  tXi ,  •  •  • , l    :x_>. 

for  all  data  objects  x^, . . . ,xn. 

For  example:   Id  X  Length:<3,  (1,3, 5, 7)>  =  <3,  4>. 

4.  Nondeterministic  Conditional  -  If  qi,...,qn  are  boolean  functions  or  con- 
stants and  f ■,,..., fn  are  functions  or  data  objects  then 

if  qx    ->    f1   D  ...    D  qn    -»    fn  fi 

is  a  nondeterministic  conditional  form  [8].  During  application  to  object  x  each 
of  the  boolean  functions,  called  guards,  are  applied  to  x.  If  any  of  the  quards 
evaluates  to  J_,  or  if  none  of  the  quards  evaluate  to  TRUE,  then  the  form  evalu- 
ates to  J_.  Otherwise  one  of  the  guards,  say  q^,  which  evaluates  to  TRUE  is  non- 
deterministically  selected  and  the  form  evaluates  to  f^:x. 

For  example, 

if    <     -»10>     ->    2  f  i 

is  a  simple  if-fi  form  mapping  Tti  X  IN  into  ]N  and  computing  the  minimum  of  two 
natural  numbers.  On  application  to  <2,3>  the  guard  <^:<2,3>  evaluates  to  TRUE 
thus  the  form  evaluates  to  1:<2,3>  =  2.  Note  that  on  application  to  <3,3>  both 
guards  evaluate  to  TRUE  thus  either  branch  of  the  conditional  can  be  taken. 
Although  either  branch  can  be  taken  the  result  is  the  same  for  this  function. 

Definitions 

A  definition  is  written  1  =  r  where  1  is  the  name  of  the  function  being 
defined  and  r  is  a  functional  form.  For  example,  we  can  name  the  minimum  func- 
tion defined  above: 

min  s  if  <     ->  1  Q   -»  2  fi 

Hereafter  we  will  sugar  the  above  notation  for  the  sake  of  readability  by 
1)  allowing  the  left  and  right  hand  side  of  definitions  to  name  their  operands, 
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2)  allowing  binary  boolean  functions  which  are  conventionally  written  in  infix 
notation  to  be  so  expressed,  3)  write 

if 

q-^x  -»  f^:x  D 

•  •  • 

qn:x  -*  fn:x 
fi 

for  conditional  forms,  and  4)  whenever  possible  replace  selector  functions  on 
n-tuples  by  the  name  of  the  object  or  functional  form  which  results  from  their 
application.  Thus  we  will  write  the  definition  of  the  minimum  function  in  the 
form: 

Min:<x,y>  =  if 

xj<y  -»  x  D 

*>.y  ->  y 

fi 

As  a  more  complex  example  of  a  function  in  FPL  consider  the  following 
recursive  definition  of  Select,  which  was  specified  in  the  previous  section. 
This  function  is  a  crucial  component  of  a  selection  sort  function  and  will  be 
synthesized  later.  Given  a  nonempty  list  of  natural  numbers  the  job  of  Select 
is  to  split  it  into  a  2-tuple  containing  the  least  element  and  the  rest  of  the 
list. 

Selectrx  —   if 

Rest:x=nil    -»    [First,  Rest]  :x    0 
Rest:x  ^  nil    -»   Compose*  (Id  X  Select)  •  [First, Rest]  :x 
fi 

Compose  :<v^,<V2,z»  =  if 

vl  — v2  ""*  <Vj_»Cons:<v2,z»  Q 
vl  — v2  ~*  <v2fCons:<vlfz» 

fi 

Here  is  a  simple  evaluation  of  Select  on  the  list  (2,5,1,4) 
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Select: (2,5,1,4)  =  Compose- (Id  X  Select) • [First, Rest] : (2,5,1,4) 
=  Compose •( Id  X  Select) :<2, (5,1,4) > 
=  Compose :<2,<1, (5,4) » 
=  <l,Cons:<2,  (5,4)» 
=  <1,(2,5,4)> 

where  Select: (5,1,4)  evaluates  to  <1,(5,4)>  in  a  similar  manner. 

Select  exemplifies  the  structure  of  simple  divide  and  conquer  algorithms, 
when  Rest:x=nil  then  the  problem  is  solved  directly,  otherwise  the  input  is 
decomposed  via  the  construction  [First, Rest] ,  recursively  solved  via  the  product 
(Id  X  Select) ,  and  the  results  composed  via  Compose. 

There  are  several  reasons  for  introducing  FPL  rather  than  using  a  known 
language  such  as  LISP.  First,  programs  in  this  functional  language  have  a 
hierarchic  structure  which  facilitates  top-down  program  synthesis.  To  construct 
a  function  from  a  given  specification  we  must  know  how  to  select  an  appropriate 
combining  form  and  adapt  it  to  the  given  problem.  The  adaptation  involves  find- 
ing functions  for  each  of  the  slots  in  the  combining  form  -  either  by  supplying 
a  primitive  function  or  by  deriving  a  specification  for  it.  For  the  adaptation 
to  be  successful  we  must  show  that  if  the  specifications  for  the  component  func- 
tions are  satisfied  then  the  resulting  functional  form  will  satisfy  the  original 
specification.  One  point  to  note  here  is  that  much  of  the  knowledge  needed  by 
the  synthesis  process  is  related  to  the  individual  combining  forms  (i.e.,  how  to 
adapt  a  certain  combining  form  to  a  given  specification)  and  the  primitive  func- 
tions (how  to  know  when  a  primitive  function  satisfies  a  given  specification) . 
So  the  structure  of  the  language  provides  a  natural  organizing  framework  for  the 
programming  knowledge  required  by  a  top-down  program  synthesizer. 

In  Section  3.2  we  present  a  program  schema  for  a  class  of  divide  and  con- 
quer algorithms  and  the  programming  knowledge  needed  to  adapt  it  to  a  specifica- 
tion. It  can  be  viewed  as  a  derived  combining  form  since  it  is  expressed  in 
terms  of  the  primitive  combining  forms  supplied  with  the  language. 

A  second  reason  for  introducing  this  language  is  that  it  allows  an  elegant 
rormulation  of  divide  and  conquer  programs.  Compare,  for  example,  the  divide 
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and  conquer  program  schema  in  Figure  1  with  its  expression  in  FPL: 

DC:x  =   if 

Primitives  -»  Direct_Solution:x  D 
-Primitives  ->  Compose*  (DC  X  DC)  *  Decomposes 
fi 

The  language  frees  us  from  the  need  to  overdetermine  the  order  of  evaluation  of 
certain  operations  which  are  naturally  independent.  For  example,  in  condition- 
als we  are  not  forced  to  determine  the  order  in  which  the  guards  are  to  be 
evaluated  -  they  are  conceptually  evaluated  in  parallel.  Also,  the  construction 
and  product  forms  allow  us  to  express  processes  which  might  otherwise  require 
the  storing  of  data  and  an  arbitrary  ordering  of  function  evaluations.  This 
conceptual  parallelism  is  useful  in  expressing  the  functions  synthesized  in  this 
paper  and  simplifies  the  synthesis  process. 


2. 3  Program  Termination  and  Well -Founded  Orderings 

Ensuring  that  a  constructed  program  will  terminate  on  all  legal  inputs  (or 
more  generally  determining  the  input  conditions  under  which  it  will  terminate) 
is  crucial  to  the  usefulness  of  a  synthesis  method.  The  usual  method  for  show- 
ing the  termination  of  a  recursive  program  depends  on  the  existence  of  a  well- 
founded  ordering  on  the  input  domain. 

A  structure  <W,  ^>  where  W  is  a  set  and  ^  is  a  binary  relation  on  W  is  a 
well-founded  set  and  ^  is  a  well-founded  ordering  on  W  if: 

1)  y   is  irreflexive:  uj^u  for  all  u€w 

2)  }•  is  assymetric:  if  u^v  then  vj^u  for  all  u,v€W 

3)  y   is  transitive:  if  u^«v  and  v^w  then  u^-w  for  all  u,v,w€w 

4)  there  is  no  infinite  descending  sequence  uQ}-  u^J-^^...  in  W. 

For  example,  H  (natural  numbers)  with  the  usual  'greater  than'  relation  >  forms 
a  well-founded  set  denoted  <U,».  More  generally  ]Nk  (k-tuples  of  natural 
numbers)  has  a  well-founded  ordering  denoted  >^  where: 

<n^,...,  n^>  >k  <n'^,...,  n'k>  iff  there  is  some  constant  m,  l£m<k,  such  that 

nj  =n'|  for  each  i<m  and  r^  >  n'm 

So  for  all  k>l  <]Nk,>k>  is  a  well-founded  set. 
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A  recursive  program  P  with  input  domain  D  can  be  shown  to  terminate  on  all 
inputs  in  the  following  way.  First,  a  well-founded  ordering  y  is  constructed 
on  D.  Then,  we  show  that  for  any  x€D  P  applied  to  x  only  generates  recursive 
applications  (calls)  to  inputs  x'  for  which  x^x'.  There  can  be  no  infinite 
sequence  Xq,x1/x2  •••  such  that  applying  P  to  x^  results  in  the  application  of 
P  to  X:  ,i  for  i  >_  0  since  the  well-founded  ordering  does  not  allow  Xq^x-. 
^x2^...  •  The  above  steps  for  ensuring  program  termination  are  an  integral 
part  of  the  synthesis  method  described  below. 

A  program  synthesis  system  will     have     knowledge     of     some     standard     well- 

k 
founded     sets     such     as     <$i,»  and  <$i    ,>k>  but  it  need  not  anticipate  ahead  of 

time  all  domains  which  will     require     well-founded     orderings.       Consequently    a 

method  for  constructing  well-founded  orderings  is  needed.     The  following  theorem 

asserts  that  if  we  have  a  domain  E  and  a  known  well-founded  set  <W,  ^>  then     any 

function  from  E  to  W  can  be  used  to  define  a  well-founded  ordering  on  E. 

Proposition  JL      Let  E  be  a  set,  let  <W,  }-w>  be  a  well-founded  set,  and  let 
h:E    ->   W  be  a  function  from  E  into  W.     The  relation    ^E  defined  by: 

u}.Eu'   iff  h(u)>-wh(u') 
is  a  well-founded  ordering  on  E. 

Proof:     1)    }»E  is  irreflexive  -  for  any  u,  h:ujt^i:u,     but     then     by    definition 
U^EU* 

2)  }»E  is  assymetric  -  if  u^-Eu'  then  h(u)  ^w  h(u')  and  h(u')  Jw  h(u) 
(by  assymetry  of    J-w)    thus  u1  Jl-j^u. 

3)  ^E  is  transitive  -  if  u^Eu'  and  u1  ^Eu"  then  h(u)  ^.^(u1)  and 
h(u')  ^^(u") .  h(u)  ^^(u")  follows  by  transitivity  of  ^w,  then  u^Eu"  follows 
by  definition  of    J-£. 

4)  <E,  ^E>  has  no  infinite  decreasing  sequence  -  if  Uq^e  u-^e  u2^e 
...  then  h(Ug)  ^w  h(u^)  ^w  h(u2)  ^  ...  contradicting  the  well-foundedness  of 
<W,  >-w>.      QED 

Proposition  1  enables  us  to  establish  a  well-founded  ordering  on  LIST(U) 
(list  of  natural  numbers)  by  simply  finding  a  function  from  LIST(JN)  to  H.  A 
suitable  primitive  function  is  Length,  so  we  may  define 
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x^y  iff  Length:x  >  Length:y 

for  all  x,y€LIST(!N) .  By  Proposition  1  we  conclude  that  <LIST(]N),  ^>  is  a 
well-founded  set.  Similarly,  Length  X  Length  (which  maps  LISTT(IN)  X  LIST(]N)  to 
UX^N)  can  be  used  to  construct  a  well-founded  ordering  }-2  on 
LIST  ( IN )  X  LIST  (]N)   where 

<x/y>>»2<x,/y,>  iff  Length  X  Length :<x,y>  >2  Length  X  Length :<x'  ,y'> 
iff  Length :x  >  Length (x')   or 

(Length :x  =  Length (x1)   and  Length (y)    >  Length (y')) 
and  so  on. 

Proposition  2;    If  <W,  }-w>  is  a  well-founded  set  then  <V1X^2^  •,,vk'^v> 
where  Vj  =W  for  some  i  €  {l,2,...,k}  and    }-v  is  defined  by 

<ulfu2,...uk>   >-v  <v1,v2/.-.vk>  iff  Uj^vj 

is  also  a  well-founded  set. 


2.4  Many-Sorted  Algebras 

Algebraic  concepts  are  playing  an  increasingly  important  role  in  formulat- 
ing the  fundamental  notions  of  computer  science.  In  this  paper  we  show  that 
divide  and  conquer  algorithms  can  be  usefully  characterized  in  algebraic  terms. 
In  particular  they  can  be  viewed  as  homomorphisms  between  appropriately  defined 
algebras  on  the  input  and  output  domains.  Accordingly,  the  synthesis  method 
described  later  involves  the  construction  of  these  algebras.  In  this  section  we 
present  the  basic  terminology  of  many-sorted  algebras  based  on  and  extending  the 
notation  of  [11,12]. 

For  any  n  6  ]N  let  n  =  {1,2, . .  .,n}.  If  A  is  a  set,  then  A+  will  denote 
AULO  -  the  extension  of  A  to  include  the  symbol  for  undefinedness.  As  usual 
the  cartesian  product  of  sets  A-^,  A2,...,  An  is  written  A-^  X  A2  X  •  •  •  X  ^  and 
aenotes  {<a^,a2,..  ,,an>  |  a^€A^  for  i€n}.  Parentheses  are  used  for  nesting  so 

A2X  (A2XA3)  =  {<a1,<a2,a3»   |  a-^A-^  a2€A2,  a3€A3) 

the  set  of  2-tuples  whose  first  component  belongs  to  A-,,  and  whose  second  com- 
ponent belongs  to  A2  X  A3. 
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Generally,  we  use  the  term  simple  many-sorted  algebra  to  denote  a  collec- 
tion of  sets  equipped  with  an  operator  defined  on  cartesian  products  of  the 
sets.  Let  S  denote  a  set  of  symbols  called  sorts.  A  simple  S-sorted  signature 
2  of  type  <W/§>  where  w€S  ,  §€S  is  a  set  containing  a  single  operator  symbol 
of  type  <w,§>.  Let  <As>sgs  be  an  S-indexed  family  of  sets.  If  w€S  and 
w  =  w1w2. .  .wn  then  Aw  denotes  the  cartesian  product  Aw  X  Aw  X  •  •  •  X  ^  .  A  £- 

algebra  A  consists  of  a  family  of  sets  <As>sgs  calle<3  t^rie   carriers  of  A,  and  an 
operator  denoted  crA  where  crA:Aw  -»  A  .  A  will  be  called  the  principal  carrier 

of  A.  A  ^-algebra  A  will  be  written  A  =  <{Cj_, . . .  ,Ck}  ,{f  }>  where  {Clr...,Ck}  are 
the  carriers  of  A  and  f  is  its  sole  operator. 

Let  A  and  B  be  ^-algebras  and  let  H  =  <hs>s  g  s  be  an  S-indexed  family  of 

functions  where  for  each  s€S,  hs:As  ->  Bg.  If  w=w-jW2...wn  let  hw  denote  the 

product  function  hw  X  h^.  X  •••  X  K,   •  Thus  if  a€Aw  then 
™1   ™2        ^n 

h  :a=<hw^:a1/  Yi^  :a2r    •••»  nwn:an>* 
H  =  <hs>sgs  is  a  (S5~) homomorphism  from  A  to  B  if  for  each  a€Aw 


w. 


h  *o~A:a  =  Og*h  :a. 


(2.4.1) 


i.e.   the  diagram  in  Figure  4  commutes.     A  ^-algebra  will  be  called  a  composition 
algebra. 

We  illustrate  this  notation  with  examples  relating  to  data     structures     and 
divide  and  conquer  algorithms. 

Example  2.4.1:  Consider  the  sort  set  S  =  {a,b}  and  simple  S-sorted  signature  £  of 


Figure  4:  Commutative  Diagram  of  a  25-homomorphism. 
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type  <ab,b>.  We  describe  two  >-algebras  called  L  and  B  as  follows: 

L  =  <{1N,LIST(]N)},  {Cons}> 

B  =  <{]N,BAGS(]N)},  {Add}> 

The  carriers  of  L  are  LQ  =  IN  (natural  numbers)  and  L^LISTfU)  (lists  of 
natural  numbers) .  The  carriers  of  B  are  Ba  =  ]N  (natural  numbers)  and 
Bu=LIST(]N)  (lists  of  natural  numbers).  The  operator  symbol  or  in  >  is  inter- 
preted in  L  as  the  function  Cons,  but  in  B  is  interpreted  as  Add  (Add  inserts  a 
number  into  a  bag  of  numbers);  i.e.  crL  is  Cons  and  aB  is  Add. 

Example  2.4.2:  There  is  a  natural  homorphism  between  algebras  L  and  B  defined  in 
Example  2.4.1.  Let  ha  be  Bag  which  maps  a  list  of  natural  numbers  x  into  the 
multiset  of  elements  in  x  (e.g.,  Bag:  (1,3,5,3,2)  ={1,3,5,3,2}).  Let  hb  be  the 
identity  function  Id.  First,  ha  and  hb  have  the  correct  domains  and  codomains: 

Id:  U    -»  U   (ha:  LQ    -»  Ba) 

Bag:  LIST(]N)  ->  BAGS(]N)   (hb:  L^  -»  B^  . 

Second,  the  homorphism  condition  (2.4.1)  is  satisfied:  For  each  a  €  IN  and 
x€LIST(]N) 

Bag* cons :<a,x>  = Add* (Id  X  Bag) *<a,x> 

(abstractly,  hb*0"L:<a,x>  =  Og*  (ha  X  hb)  :<a,x>) . 

The  inverse  £    of  a  simple  S-sorted  signature  £  of  type  <w,§>  is  a  set 
containing  a  single  operator  symbol  of  type  <§,w>.  A  £  ~  -'■-algebra  A  is  a  family 


of  sets  <Ag>sgs  and  an  operator  crA:  A  -»  Aw.  Let  A  be  a  £  ■'■-algebra,  B  a 


^-algebra,  and  let  H  =  <hs>sgs  be  an  S-indexed  family  of  functions  such  that  for 
each  s€S  hs:Ag  -»BS.  H  is  a  (£  ~ 1^) -homomorphism  from  A  to  B  if  for  each  x€A 

such  that  o~A:x  is  defined 

hg:x  =  aB-hw-aA:x  (2.4.2) 

i.e.,  the  diagram  in  Figure  5  commutes.  A  £~ -'--algebra  will  be  called  a  decom- 
position algebra. 

Example  2.A.Z:   Consider  a  simple  S-sorted  signature  2  of  type  <ab,b>.   Consider 
LS  and  LC  which  are  *>    and  ^-algebras  respectively  where: 
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Figure  5:  Commutative  Diagram  of  a  £  -'•^-homomorphism. 


LS  =  <{]N,LIST(]N)},  {Select} > 

LC  =  <{]N,LIST(]N)},  {Cons}> 

LS  has  carriers  LSa  =  M  and  LSb  =  LIST(]N)  and  operator  Select:  LIST(]N)  -» 
UXLIST(IN).  Select  splits  a  list  of  natural  numbers  into  its  least  element 
and  the  rest  of  the  list  as  discussed  earlier.  LC  has  carriers  LCa  =  Tti  and 
LCb  =  LIST(]N)  and  operator  Cons:  ]N  X  LIST(IN)  _»  LIST(]N).  Letting  hb  be  the 
function  Sort,  which  sorts  a  list  of  numbers,  and  ha  the  identity  function  Id, 
we  have  a  natural  homomorphism  from  LS  to  LM.  First,  Sort  and  Id  have  the 
required  domains  and  codomains: 

Id:]N  -»  U       (ha:LSa  "*  ^a^ 

Sort :  LIST  (IN)  ->  LIST(]N)    (hD:LSb  -»  LCb) 

and  the  homomorphism  condition  (2.4.2)  is  satisfied:  for  any  x€LIST(]N)  such 
that  Select :x  is  defined. 

Sort:x  =  Cons*  (Id  X  Sort)  *Select:x. 

Programmers  will  recognize  this  identity  as  the  essence  of  a  selection  sort 
algorithm.  It  states  that  there  are  two  ways  to  sort  a  list  x:  either  apply 
Sort  to  x  or  decompose  x  via  Select  into  a  number  a  and  list  y,  apply  Sort  to  y 
yielding  sorted  list  z  then  Cons  a  onto  it. 

It  will  be  useful  to  relax  the  definition  of  a  £  ^-homomorphism  slightly 
in  order  to  allow  homomorphisms  which  map  a  restricted  portion  of  a  decomposi- 
tion algebra  E  to  a  composition  algebra  T.  Let  K  be  a  relation  on  E  .   A  K- 

restricted  2   5  homomorphism  from  E  to  T  is  an  S-indexed  family  of  functions 
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H  =  <hs>s  g  s  such  that 

1)  hs:   Es    -»   Ts  for  each  s€S  and 

2)  for  each  x€E     such  that  K:x,  h   :x  =  aT*hw*crE:x. 

§  s 

When  K:x  is  Defined  *crE:x  then  we  get  back  the  original  definition  of  a  £  "  2- 
homomorphism. 


2.5  Derived  Preconditions 

The  synthesis  method  described  later  consists  of  a  sequence  of  tasks  many 
of  which  are  carried  out  by  a  kind  of  deductive  engine  described  in  this  sec- 
tion. Only  those  aspects  of  the  engine  needed  for  our  synthesis  examples  are 
presented  here.  More  details  may  be  found  in  [20]. 

2.5.1  The  Precondition  Problem 

The  traditional  problem  of  deduction  has  been  to  fknd  a  proof  of  a  given 
formula  in  some  theory.  A  more  general  problem,  which  we  call  the  precondition 
problem ,  is  most  simply  stated  in  the  propositional  calculus:  given  a  goal  A  and 
hypothesis  H,  find  a  formula  P,  called  a  precondition,  such  that  PAH  =>  A  is  a 
tautology.  In  other  words  P  provides  any  additional  premises  under  which  A  can 
be  shown  to  follow  from  H. 

In  this  paper  we  derive  preconditions  in  a  many-sorted  first-order  theory 
•J>.   The  data  types,  functions  and  predicates  of  *f  needed  for  our  examples  are 
listed  informally  in  the  Appendix.  The  notions  of  term,  atomic  formula,  literal 
and  (well-formed)  formula  have  their  usual  meaning  [15].  We  make  use  of  a  dis- 
tinguished subset  of  the  theorems  of  «J>  called  known  theorems  which  are  assumed 
to  be  immediately  available  to  the  deductive  system.  The  set  of  known  theorems 
may  change  over  time  but  initially  includes  all  axioms  of  •£.  All  of  the  known 
theorems  required  by  the  examples  are  listed  in  the  Appendix. 

We  introduce  the  notion  of  a  precondition  in  a  first-order  logic  by  an 
example.  Consider  the  following  formulas 

Vi€]N  Vj€u    [i2<j2]  (2.5.1) 

Vi€]N  Vj€U    [i=0    =*    i2<j2]  (2.5.2) 
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The  first  is  invalid,  the  second  valid.  All  that  we  have  done  in  (2.5.2)  is 
insert  a  sufficient  condition,  i=0,  on  the  matrix  i^£j^  in  (2.5.1).  We  call 
"i=0"  an  {i}-precondition  of  (2.5.1)  because  it  contains  only  the  variable  i, 
and  when  we  use  it  as  we  did  in    (2.5.2)   we  obtain  a  valid  statement. 

Formally,  let  QiX-^  Q2x2***^nxn  G  be  a  closed     formula     not     necessarily     in 
prenex     form     where     Q^     is     either     3      or     V  for  i=l,2,...,n.     A  {x-jX2.  •  •*n}- 
precondition  of  Q-jX-^  Q2x2***^nxn  G  *s  a  c3uantif ier-free  formula  P  dependent  only 
on  variables  ^^2' "  ' '^r\  sucn  tnat 

Q1x1Q2x2...Qhxn[  P=»G  ] 
is  valid  in  •$■.     P  is  also  a  weakest  {x^Xg* » .xn} -precondition  if 

Q1x1Q2x2...Qnxn[  P<=»G  ] 
is  valid  in  *$. 

Example  2.5.1;  Consider  the  formula  Vi  €  H  V j  €  K    [i2<j2  ] 

a)  FALSE  is  a   {} -precondition  of    (2.5.1)   since 
Vi€]N  V j  €  IN    [FALSE    =>    i2_<j2]   is  valid  in  «f, 

b)  i=0  is  a   {i}-precondition  of   (2.5.1)   since 
Vi€N  Vj€^N    [i=0    =>    i2<j2]   is  valid  in  •£. 

c)  i  < j  is  a   { i , j } -precond i tion  of   (2.5.1)   since 
Vi€  H   V j  €  H    [i  <  j    =>    i2<  j2]    is  valid  in  •£. 

Furthermore,  note  that  each  of  the  above  preconditions  are  in  fact  weakest 
preconditions  since  the  implication  signs  can  each  be  replaced  by  equivalence 
signs  without  affecting  validity.  Note  also  that  for  any  goal  formula  and  set 
of  variables  the  constant  FALSE  is  a  precondition. 

In  general  a  given  goal  may  have  many  preconditions.  Characteristics  of  a 
useful  precondition  seem  to  depend  on  the  application  domain.  In  program  syn- 
thesis we  want  preconditions  which  are  a)  easily  computable,  b)  in  as  simple  a 
form  as  possible,  and  c)  as  weak  as  possible.  (Criterion  (c)  prevents  the 
boolean  constant  FALSE  from  being  an  acceptable  precondition  for  all  goals.) 
Clearly  there  is  a  tradeoff  between  these  criteria.  We  currently  measure  each 
criterion  by  a  separate  heuristic  function,  then  combine  the  results  to  form  a 
net  complexity  measure  on  preconditions.  We  assume  that  such  a  complexity  meas- 
ure ranges  over  a  well-founded  set  (such  as   H  under  the  usual  >     relation)     and 
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that  we  seek  to  minimize  complexity  over  all  preconditions. 

Example  2. 5. 2:  Consider  again  the  formula  Vi€]N   V  j  6  H    [i2<  j2]   for  which     we 
want  a  useful   {i,j} -precondition.     Three  candidates  come  to  mind:  FALSE,   i2  <  j2, 
and  i  <  j.     FALSE  is  certainly  simple  in  form  and  semantics  but  it  is     not    weak. 
Both     i2<j2    and     i<  j  are  weakest  preconditions  however  i  <  j   is  the  simpler  of 
the  two.     Thus  i  <^  j  seems  the  most  desireable. 

The  generality  of  the  precondition  problem  allows  us  to  define  several 
well-known  problems  as  special  cases.  The  formula  simplification  problem 
involves  transforming  a  given  formula  into  an  equivalent  but  simpler  form.  For- 
mula simplification  can  be  viewed  as  the  problem  of  finding  a  weakest 
{xi/...x  }  -precondition  of  a  given  formula  Q±x±» .  .  Q^x^.  For  example  in  the 
previous  example  we  found  i  _<  j  to  be  a  result  of  simplifying  i*<,  j   . 

Theorem  proving  is  the  problem  of  showing  that  a  given  formula  is  valid  in 
a  theory  by  finding  a  proof  of  the  formula.  In  terms  of  preconditions,  theorem 
proving  is  the  task  of  finding  a  weakest  {} -precondition  of  a  given  formula.  A 
precondition  in  no  variables  is  one  of  the  two  propositional  constants  TRUE  or 
FALSE.     If  we  show  that 

Eji€  ]NVj  €  ]N[TRUE   «=»   i2<j2] 

is  valid  in  *f  then  we  also  have  shown  that 

3i€  ]NVj€  H[i2<  j2] 

is  valid  in  *f. 

Formula  simplification  and  theorem  proving  are  opposite  extremes  in  the 
spectrum  of  uses  of  preconditions  since  one  involves  finding  a  weakest  precondi- 
tion in  all  variables,  and  the  other  involves  finding  a  weakest  precondition  in 
no  variables.  Between  these  extremes  lies  a  use  of  preconditions  which  is  crit- 
ical to  the  synthesis  method  described  later.  Suppose  that  we  wish  to  establish 
a  relationship 

Vx2  Vx2  Vx3  Vx4  [A:<x1,X2>AB:<x2fX3>AC:<x3,x4>=»D:<x1,x4>](2.5.3) 

where  B,  C,  and  D  are  known,  but  A  is  unknown  and  needs  to  be  determined.  Any 
{x-^x^ -precondition  of  (2.5.3)  can  be  used  for  A.  To  see  this  let  A,:<x1,x2> 
be  any  such  precondition  so 

Vx2  Vx2  Vx3  Vx4  [A':<x1/X2>=»(B:<x2,X3>AC:<X3,x4>=»D:<x1,x4»] 
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is  valid.  But  this  is  equivalent  to 

Vx2  Vx2  Vx3  Vx4  [A,:<x1,x2>AB:<x2fX3>AC:<x3,x4>=»D:<x1,x4>] 

In  this  example  precondition  derivation  is  similar  to  solving  a  linear  equation 
in  which  all  but  one  of  the  variables  have  been  given  values.  A  relation  analo- 
gous to  (2.5.3)  must  be  established  among  the  operators  of  a  simple  divide  and 
conquer  algorithm  (the  "separability  condition"  of  Theorem  1  in  Section  3.2). 
When  all  but  one  of  the  operators  are  known  we  use  preconditions  in  order  to 
derive  the  output  condition  of  the  unknown  operator. 

While  we've  shown  that  the  precondition  problem  in  a  sense  is  more  general 
than  that  of  theorem  proving  we  will  see  in  the  next  section  that  actually 
deriving  preconditions  is  much  like  a  theorem  proving  process.  The  crucial 
difference  is  that  in  deriving  a  precondition  P  for  a  goal  G  we  end  up  proving 
the  validity  of  a  formula  involving  P  and  G  but  we  did  not  know  ahead  of  time 
what  we  were  going  to  prove!  The  proof  process  itself  provides  some  of  the 
premises  of  the  formula  which  is  finally  proved  valid. 


2. 5. 2  A  Formal  System  for  Deriving  Preconditions 
Goal  Preparation 

In  presenting  a  set  of  rules  which  allow  us  to  derive  preconditions  we  use 
the  notation  ^  as  an  abbreviation  of  the  formula 

h1  A  h2  A  ...  A  hk  =>  A 

where  H=  {h-^,!^ .  •  ./h^}.  A  goal  statement  ^  and  the  known  theorems  of  *$  are 
prepared  as  follows.  First,  all  occurences  of  equivalence  (<=»)  and  implication 
(  => )  signs  are  eliminated  and  negation  signs  are  moved  in  as  far  as  possible. 
H  and  the  known  theorems  of  •£  are  then  skolemized  in  the  usual  way  [14],  i.e., 
existentially  quantified  variables  are  replaced  by  skolem  functions  of  the 
universally  quantified  variables  on  which  they  depend.  Quantifiers  are  then 
dropped  with  the  understanding  that  all  remaining  variables  are  universally 
quantified.  The  goal  A  is  skolemized  in  a  dual  manner  with  universally  quanti- 
fied variables  replaced  by  skolem  functions  of  the  existential  variables  on 
which  they  depend.  All  quantifiers  are  then  dropped  with  the  understanding  that 
all  variables  in  A  which  remain  are  existentially  quantified.  The  preparation 
of  A  is  equivalent  (via  duality  of  goals  and  assertions)  to  preparing  -A  as  an 
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hypothesis  then  taking  the  negation  of  the  result  as  our  prepared  goal. 

All  of  the  derivations  treated  in  this  paper  involve  only  universally  quan- 
tified variables.  Consequently  during  goal  preparation  each  variable  in  the 
goal  is  replaced  by  a  skolem  function  of  no  arguments  (i.e.  a  constant).  Rather 
than  invent  a  special  notation  for  these  skolem  constants  we  will  simply  use  the 
variable  name  itself.  Thus  in  example  derivations  symbols  for  variables,  such 
as  "x" ,  should  be  regarded  as  skolem  constants. 

Reduction  Rules 

Rules  which  reduce  a  goal  statement  to  two  subgoal  statements  are  expressed 
in  the  following  form: 


<P0>  AQ 


<P1>   Al 


<P2>  A2 


where  Aq,Aj,  and  A2  are  goal  formulas,  HQ,  H±,   and  H2  are  sets  of  hypotheses, 

PQ,  p, ,  and  P2  are  formulas  (the  derived  preconditions) ,  and  ©  is  either  V  or 

Ai 
A*  A  rule  of  this  form  asserts  that  if  P^  is  a  (weakest)  precondition  of  H* 

where  i=l  or  2  then  PQ  is  a  (weakest)  precondition  of  H  .  PQ  generally  is  P^  1& 

P2.  Typically  a  deductive  process  also  returns  a  substitution  for  any  variables 
in  the  goal.  Substitutions  do  not  play  an  important  role  in  the  examples  of 
this  paper  so  for  simplicity  we  omit  them  whenever  possible.  They  are  fully 
treated  in  [20]. 

Rules  which  reduce  a  goal  statement  to  one  subgoal  are  notated 


<P0>  AQ 


<P1>  Al 
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Occasionally,  as  in  the  application  of  known  theorems  which  are  implica- 
tions, the  relation  between  goal  and  subgoals  is  not  one  of  equivalence  but 
implication.  Rules  of  this  kind  are  notated 

<P0>  AQ 
H0 


<P1>  Al 

Hl 

Al 
which  asserts  that  if  P-^  is  a  precondition  of  ^  then  PQ  is  a  precondition  of 

An 

H  .   For  rules  of  this  kind  we  cannot  assert  that  PQ  is  a  weakest  precondition 

A  A 

of  jj  even  if  P^  is  known  to  be  a  weakest  precondition  of  H*. 

The  following  rules  are  for  the  most  part  extensions  of  typical  goal  reduc- 
tion rules  [5,14] . 


Rl.  Reduction  of  Conjunctive  Goals 

<P1   A  P2>   A  A  B 
H 


<P2>  A         <P2>  B 

H  H 


R2.  Reduction  of  Disjunctive  Goals 

<P1  V  P2>       A  V  B 
H 


<PjL>     A  <P2>     B 

H  H 
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R3.  Application  of  an  Equivalence  Theorem 


<P>  A 

H 


<p>  ce 

HO 


if  C<=J>B  is  a  known  theorem  of  •$ 
or  an  hypothesis  in  H  and  9  unifies  {A,B} 


R4.  Application  of  an  Implicational  Theorem 


<P>  A 

H 


<p>  ce 

HO 


if  C=»B  is  a  known  theorem  of  «J» 
or  hypothesis  in  H,  where  9  unifies  {A,B} 


R5.  Substitution  of  Equal  Terms 


<P>  A(r) 
H 


<P>  A(s) 
H 


R6.  Conditional  Equality  Substitution 


if  r=s  is  an  hypothesis  in  H 
or  a  known  theorem  of  *f 


<P>  A(r) 
H 


If  B 


<P>  A(S2)9192 


Hel92 


=»  s,  =s,  is  a  known  theorem 

where  9-,  unifies  {rfs^}  and 

92  unifies  B9-^  with  a 

hypothesis  or  known  theorem. 


Primitive  Rules 

A  reduction  rule  generates  a  precondition  for  a  goal  by  decomposing  it  into 
subgoals,  then  composing  the  derived  preconditions  of  the  subgoals.  We  also  use 
two  rules,  called  primitive  rules,  which  can  directly  generate  a  precondition 
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for  a  goal.  Both  are  described  by  notations  of  the  form   <p>  ^       which 
assert  that  P  is  a  precondition  of  ^  if  the  associated  condition  holds. 

PI.   <TRUE>  A        if  A  can  ^  directly  evaluated  to  TRUE,  or  if  9  unifies 

{A,B}  where  B  is  a  known  theorem  of  "for  B€H. 

P2.  <H' =^A'>  A     j£  we  QQQk  a   {x,,...,x  } -precondition  and  A'  depends  only 

n 
on  the  variables  xlf...,x  and  H'  has  the  form  A  h.-  where 

j  =  1  xj 

H  =  {hlfh2/.../hk}  and  {ni.}-j  =  ira  C  H  and  for  each  j, 
l£j_<m,  h^  m   depends  only  on  the  variables  x±,X2'  ••  *'xn* 

The  primitive  rule  PI  always  generates  weakest  preconditions  but  P2  does  not  in 
general  unless  A'  is  A  and  H'  is  H. 

The  Deduction  Process 

The  derivation  of  a  precondition  of  goal  statement  ^  can  be  described  by  a 
two  stage  process.  In  the  first  phase  reduction  rules  are  repeatedly  applied  to 
goals  reducing  them  to  subgoals.  Primitive  rule  PI  is  applied  whenever  possi- 
ble. If  no  reduction  rules  can  be  applied  to  a  goal  (or  if  we  simply  desire  to 
cut  short  the  deduction)  primitive  rule  P2  is  applied.  The  result  of  this 
reduction  process  is  a  goal  tree  in  which  1)  nodes  represent  goals/subgoals,  2) 
arcs  represent  reduction  rule  applications,  and  3)  leaf  nodes  represent  goals  to 
which  a  primitive  rule  has  been  applied. 

The  second  phase  involves  the  bottom-up  composition  of  preconditions.  Ini- 
tially each  application  of  a  primitive  rule  to  a  goal  yields  a  precondition. 
Subsequently  whenever  a  precondition  has  been  found  for  each  subgoal  of  a  goal  ^ 
then  a  precondition  is  composed  for  ^  according  to  the  reduction  rule  employed. 
Each  newly  composed  precondition  is  then  run  through  a  simplification  process. 

Usually  several  reduction  rules  can  be  applied  to  a  given  goal  and  each 
rule  will  generate  a  precondition.  We  make  use  of  a  complexity  measuring  func- 
tion to  select  that  precondition  of  least  complexity  among  the  alternatives. 
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Example  2.j>._3:   Suppose  that  we  wish  to  derive  a   {xQ/XjyX^-precondition  of 

V<X0,x1,x2>€LIST(W)  XLIST(W)  XLIST(W) 
V<ZQ,zlfz2>€LIST(]N)  XLIST(W)  XLIST(W) 

[Bag:xi  =  Bag:z1  A  Ordered rz^  A  Bag:x2  =  Bag:z2  A  Ordered:z2  A 
Append :<zlrz2>  =  zQ    =»    Ordered:zQ]. 

This  precondition  problem  is  taken  from  the  synthesis  of  a  Quicksort  algorithm 
in  Section  4.3.3.  A  goal  tree  representing  a  formal  derivation  of  the  precondi- 
tion Bagix^  <  Bag:x2  is  9*ven  in  Fi9ure  6.  In  this  example  and  all  that  follow  we 
annotate  the  arcs  of  goal  trees  with  the  name  of  the  rule  and  known  theorem  or 
hypothesis  used  and  note  the  primitive  rule  used  on  each     leaf     node.       In     this 


Hypotheses:     hi.  Bagix-^  =  Bag:z, 

h2.  Ordered  :z-, 

h3.  Bag:x2  =  Bag:z2 

h4.  Ordered :z2 

h5.  Append :  <zlfz2>  =  Zq 

Variables:      {xQfX^x,,} 


Goal   1: 


<Q>     Ordered :Zq 
R5  +  h5 
<Q>     Ordered: Append :<z ^, z2> 

R3  +  L13 


<Q>     Ordered :zj_  A  Ordered:z2  A  Bagzz^ Bag:z2 


R1,R1 


<TRUE>     Ordered :zj         <TRUE>     Ordered :z2     <Q>     Baq:z^<  Bag:z2 


PI  +h2 


Pl+h4 


R5  +  hl,   R5+h3 
<Q>     Bag:x2£Bag:x2 


P2 


where  Q  is     BagtXj  <  Bag:x2 


Figure  6:     Example  Derivation  of  a  Precondition 
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example  the  given  goal  Ordered :zn  is  reduced  by  application  of  the  rule  R5 
(equality  substitution)  together  with  hypothesis  h5.  The  resulting  subgoal 
Ordered:  Append  :<z-,,z2>  is  further  reduced  by  rule  R3  (application  of  equivalence 
theorems)    together  with  the  known  theorem 

Ordered  :x^  A  Ordered  :x2  A  *i  £x2  ^  Ordered  'Append  :<x ±, x2>. 

(called  LI 3)    to  the  subgoal 

Orderedtz-^  A  Ordered:z2  A  Bagtz-^  <  Bag:z2. 

This  conjunction  is  decomposed  by  two  applications  of  rule  Rl  (reduction  of  con- 
junctions) into  the  three  subgoals  on  the  fourth  line.  The  primitive  rule  PI 
matchs  the  first  subgoal  Ordered :z^  with  hypothesis  h2,  generating  precondition 
TRUE.  Similarly,  PI  matchs  the  second  subgoal  Ordered :z2  with  hypothesis  h4, 
generating  precondition  TRUE.  The  third  subgoal  Bag:z^_<  Bag:z2  is  reduced  by 
the  application  of  rule  R5  twice  with  hypotheses  hi  and  h3  yielding  subgoal 
Bag:xi  £Bag:x2.  This  subgoal  depends  only  on  the  variables  Xi  and  x2  and  we  can 
apply  primitive  rule  P2  yielding  the  precondition  Bagrx-^  £Bag:x2  (which  we  call 
Q  for  brevity) .  In  the  composition  phase  of  the  derivation  the  preconditions 
generated  by  the  primitive  rules  are  passed  up  the  goal  tree  and  composed.  The 
composed  precondition  of  the  subgoal 

Ordered :z-^  A  Ordered :z2  A  Bagiz-^  _<  Bag:z2 

is  in  fact 

TRUE  A  TRUE  A  Bagix-j^  <  Bag:x2 

which  simplifies  to  Bag:xi  _<  Bag:x2.  In  this  example  and  the  sequel  we  record 
only  the  simplified  form  of  a  composed  precondition.  Finally  Bag:x-.  <Bag:x2  is 
passed  all  the  way  back  up  the  tree  to  become  the  derived  precondition  of  the 
original  goal. 
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3.  Top-Down  Program  Synthesis 

In  Section  1  we  discussed  the  notion  of  top-down  design.  We  now  describe 
the  general  structure  of  a  system  for  the  top-down  design  of  algorithms.  As 
depicted  in  Figure  6,  the  system  takes  as  input  a  incomplete  specification  of  a 
problem  and  generates  as  output  an  algorithm  plus  completed  specification.  The 
advantage  of  using  incomplete  specifications  is  threefold.  First,  the  user  need 
not  be  concerned  with  how  to  solve  his/her  problem  but  rather  can  focus  on  the 
nature  and  structure  of  the  problem  itself.  Second/  other  than  having  the  user 
supply  a  complete  program,  it  is  only  with  specifications  that  we  are  able  to 
completely  verify  that  the  user's  intentions  have  been  met  by  a  potential  solu- 
tion. Finally,  incomplete  specifications  are  easier  to  create  since  the  user 
need  not  be  concerned  with  supplying  all  necessary  input  conditions  -  the  system 
will  supply  them  automatically. 

The  programming  knowledge  needed  for  top-down  program  design  is  organized 
about  the  two  central  aspects  of  the  design  process:  1)  how  to  directly 
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Figure  6.  Structure  of  a  Top-Down  Program  Synthesis  System. 
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construct  a  solution  to  a  so-called  primitive  problem,  and  2)  how  to  break  a 
nonprimitive  problem  down  into  subproblems  and  assemble  a  solution  based  on 
solutions  to  subproblems.  Knowledge  about  the  first  aspect  is  presented  in  Sec- 
tion 3.1.  Broadly  we  envision  knowledge  of  the  second  kind  coming  in  the  form 
of  design  theories  for  various  classes  of  algorithms.  A  design  theory  consists 
of  three  parts: 

1.  A  program  schema ,  which  is  a  parameterized  program  template  with  uninter- 
preted symbols  for  subprograms.  The  program  schema  characterizes  the  structure 
common  to  algorithms  in  the  class. 

2.  A  formula  providing  sufficient  conditions  for  the  total  correctness  of  the 
schema  with  respect  to  a  generic  problem  specification.  Necessarily  these  con- 
ditions are  formula  schemas  containing  uninterpreted  symbols  for  the  specifica- 
tions of  subprograms  in  the  program  schema,  and  for  predicates  in  the  problem 
specification.  Note  that  they  link  a  problem  specification  and  a  program 
schema . 

3.  A  design  method  which  attempts  to  instantiate  the  schema  in  order  to  satisfy 
a  given  problem  specification.  It  works  by  deriving  subproblem  specifications 
in  such  a  way  that  the  sufficient  conditions  are  satisfied.  Loosely  speaking, 
in  our  approach  a  design  method  uses  the  sufficient  conditions  to  "solve  for" 
subproblem  specifications. 

The  main  result  of  this  paper  is  a  design  theory  for  the  class  of  simple  divide 
and  conquer  algorithms. 

The  Programming  Knowledge  Base  in  Figure  6  consists  of  two  parts.  The  Data 
Structure  Knowledge  Base  stores  all  system  knowledge  about  data  types,  their 
operators,  and  their  properties.  It  is  discussed  in  Section  3.1.  The  Library 
of  Design  Theories  is  a  collection  of  design  theories  as  discussed  above.  A 
program  schema  for  the  class  of  simple  divide  and  conquer  algorithms  and  suffi- 
cient conditions  for  correctness  of  the  schema  are  presented  in  Section  3.2.  In 
Section  3.3  we  present  our  design  method  for  simple  divide  and  conquer  algo- 
rithms. Several  of  our  examples  require  the  synthesis  of  simple  conditional 
programs.  A  collection  of  design  methods  for  conditional  programs  will  be 
treated  elsewhere,  but  assumed  as  given  for  our  present  examples. 

The  Synthesis  Control  Module  controls  the  top-down  design  process.  Among 
its  tasks  are  obtaining  specifications  from  the  user,  selecting  and  applying 
design  theories,  and  managing  the  resulting  tree  structure.   Included  in  the 
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Control  Module  is  a  precondition  engine  as  discussed  in  Section  2.5. 

We  are  currently  constructing  a  system  with  the  structure  of  Figure  6.  A 
precondition  engine  has  been  built  which  can  handle  most  of  the  derivations 
given  in  the  example  syntheses  below. 


3.1  Data  Structure  Knowledge  Base 

The  data  structure  knowledge  base  (DSKB)  is  the  repository  of  all  system 
knowledge  about  data  types,  their  functions,  algebras,  and  properties.  The  data 
types  represented  in  the  DSKB,  called  known  data  types,  may  change  over  time  but 
initially  include  the  primitive  types  of  the  target  programming  language.  The 
functions  of  the  DSKB,  called  known  functions,  also  may  change  over  time  under 
user  definition  but  initially  include  the  primitive  functions  of  the  target 
programming  language.  The  algebras  in  the  DSKB,  called  known  algebras,  may  also 
change  over  time  but  initially  include  at  least  one  constructive  algebra  for 
each  known  data  type.  Logical  statements  involving  the  known  data  types  and 
functions,  called  known  theorems,  also  may  change  over  time  as  new  theorems  are 
proved  or  added  by  a  user  but  initially  include  the  axioms  which  describe  the 
primitive  data  types  and  functions  of  the  programing  language.  The  DSKB  assumed 
for  the  purposes  of  this  paper  is  presented  in  the  Appendix. 

The  organization  (and  structure)  of  the  DSKB  depends  on  the  various  roles 
it  plays  in  the  synthesis  system.  The  DSKB  is  used  as  the  lexicon  of  the 
specification  language.  We  allow  in  specifications  any  formula  constructable 
from  the  known  types  and  functions.  As  the  DSKB  changes  over  time  so  does  the 
specification  language.  From  the  specification  language  point  of  view  the  DSKB 
defines  a  first-order  language. 

The  precondition  engine  uses  the  DSKB  as  a  knowledge  base  of  theorems  to 
use  during  its  derivations.  From  this  point  of  view  the  DSKB  is  a  partial 
representation  of  a  first-order  theory  (partial  in  the  sense  that  only  the  known 
theorems  are  explicitly  represented) . 

As  previously  indicated  the  synthesis  method  for  divide  and  conquer  pro- 
grams involves  the  construction  of  algebras  on  various  domains.  Thus  organiza- 
tion of  the  data  types  and  functions,  relations,  and  theorems  along  the  lines  of 
algebras  and  subalgebras  may  be  useful. 
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Although  we  do  not  include  it  here,  ideally  the  DSKB  also  requires  consid- 
erable programming  knowledge  of  the  kind  described  by  Barstow  in  [3].  The  rea- 
son is  this:  the  synthesis  method  constructs  a  program  out  of  known  operators 
and  relations  mapping  the  input  type  to  the  output  type  given  in  the  specifica- 
tion. If  the  input  and/or  output  types  or  operators  or  relations  are  not  primi- 
tive then  the  constructed  algorithm  must  be  further  refined  into  target  language 
primitives.  Barstow  has  explored  the  kind  of  knowledge  and  processing  required 
to  perform  this  refinement  process. 

Matching  Known  Functions  Against  a  Given  Specification 

The  top-down  decomposition  process  terminates  in  specifications  which  can 
be  satisfied  by  known  functions.  Consequently  a  basic  operation  of  the  DSKB  is 
to  retrieve  any  known  functions  satisfying  a  given  specification.  The  following 
two  theorems  provide  the  basis  for  two  variants  of  this  operation.  Proposition 
3  suggests  a  matching  operation  which  is  useful  when  we  have  a  given  specifica- 
tion and  we  wish  to  see  if  any  of  a  library  of  functions,  each  described  by  a 
specification/  satisfy  it.  Proposition  4  is  useful  when  a  known  function  is 
described  not  by  specification  but  by  axioms  (known  theorems) . 

Proposition  3:  Let  ||  j_  =  <D-j_,Rj_,Ij_,0-|_>  and  Tj*2  =  <D2'R2'I2'°2>  ^  specifications. 
If 

(a)  D2  fi   D-l 

(b)  R2   fi   R2 

(c)  J  is  an   {x} -precondition  of  Vx€D2   [I2:x    =>    Ipx]  / 

(d)  K  is  an  {x} -precondition  of 

Vx€D2  VzCSj    [I2:x  A  01:<x,z>    =>    02:<x,z>] 

then  any  function  satisfying  ||  ^  also  satisfies  ||  2  with  derived  input  condition 
J  A  K. 

Proof:  Let  F  be  any  function  satisfying  ||  ,,   thus 

VxCDjl  [I-^x  =*•  01:<x/F:x>]. 
We  must  show 

Vx€D2[I2:x  A  J:x  A  K:x  =»  02:<x,F:x>] 
where  J  and  K  are  preconditions  satisfying  conditions  (c)  and  (d)  respectively. 
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Let  x€D2  and  assume  I2:x  A  J-*x  A  K:x.  By  conditions  (a)  and  (c)  we  can  infer 
I,:x.  Since  F  satisfies  J\  ±  we  obtain  01:<x,F:x>.  Since  F:x€R1#  and  by  condi- 
tion (d)  K:x  A  I2:x  A  01:<x,F:x>  =>  02:<x,F:x>,  we  obtain  via  modus  ponens 
that  0?:<x,F:x>.  Since  x  was  taken  as  an  arbitrary  element  of  D2  it  follows 
that 

Vx€D2    [I2:x   A  J:x  A  K:x    ==>    02:<x,F:x>] 
i.e.  F  satisfies   Tj"2  with  derived  input  condition  I2  A  J  A  K.     QED 

Example  3.1.1:  One  of  the  known  functions  of  the  DSKB,  called  Listsplit,  takes  a 
list  and  splits  it  roughly  in  half.     It  is  specified  as  follows: 

Listsplit:xQ  =  <xlfx2>  such  that  xQ  =  Append :<xlfx2>  A 

Length :x^  =  Length :Xq  div  2  A  Length :x2  =  (1  +  Length:xQ)   div  2 

where  Li stspl i t : LIST ( ]N )     ->    LIST(IN)  X  LIST(]N) . 

By  x  div  k  we  mean  integer  division  by  k.  Thus  5  div  2  =  2.  During  the  synthesis 
of  a  mergesort  algorithm  we  derive  the  following  specification: 

Decompose :yQ  =  <y^,y2>  such  that  Length:yQ  >  Lengthy  A  Length:y0  >  Length:y2 
where  Decompose:  LIST  (]N)     ->    LIST  (  M )  X  LIST  (IN) . 

We  can  match  Decompose  and  Listsplit  using  Proposition  3.  Since  the  input 
domain,  the  output  domain,  and  the  input  condition  coincide  it  remains  to  derive 
a  {Yq} -precondition  of 

V<y0ryiry2>€LIST(]N)  XLIST(]N)  XLIST(]N)    [y0=append:<y1,y2>  A 
Length :y^  =  Length :yQ  div  2  A  Length :y2  =  (1  +  Length:y0)  div  2 
=>    Length  :yQ>Length:y j  A  Length :yQ>Length :y2] . 

We  have  created  the  precondition  problem  by  making  the  following  instantiations 
into  the  condition   (d)   of  Proposition  3: 

LIST(U)    replaces  D1,R-L,D2fR2 

TRUE  replaces  Ij/I2 

the  output  condition  of  Listsplit  replaces  0-.,  and 

the  output  condition  of  Decompose  replaces  02. 

In  Figure  1,  we  derive  the  precondition  Length:yQ  >  0  A  Length:yQ  >  1  which 
simplifies     to  Length:y0>l.     Thus  according  to  Proposition  3  Listsplit  satisfies 
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the  specification  of  Decompose  with  derived  input  condition  Length:y0>l.  This 
means  that  we  can  use  the  function  Listsplit  for  the  problem  Decompose  provided 
that  it  is  never  passed  an  argument  of  length  zero  or  one. 


Hypotheses:      1.     xQ  = append :<xlfx2> 

2.  Length :x j,  =  Length :Xq  div  2 

3.  Length:x2  =  (1  +  Length:xQ)   div  2 

Variables:      {xQ} 

Goal   1:  <Q1>     Length:xQ  >  Length:x^ 

I  R5+h2 
<Q1>     Length :xq  >  Length :Xq  div  2 
t  R4+n2 
<Q1>     Length :Xq  +  Length :Xq  >  Length:x0 

I  R3  +  nl 
<Q1>     Length :xQ  >  0 
P2 
where  Ql  is  Length :Xq>0 

Goal   2:  <Q2>     Length :xQ  >  Length :x2 

I  R5+h3 
<Q2>     Length:x0  >    (1  +  Length:xQ)   div  2 

lR4+n2 


t' 


<Q2>     Length :xn  +  Length :xn  >  1+Length:x 


l  n      S      i    T^   1-SII  ItJUUAA 


R3+nl 
<Q2>     Length :xQ  >  1 
P2 
where  Q2  is  Length :xq>1 

Figure  7:     Matching  the  specification  of  Decompose  with  the  specification  of  Listsplit 
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Proposition  4:   Let  F  be  a  function  with    domain     D^     and     codomain     F^     and     let 

^2  =  <D2fR2'I2'°2>  be  a  specification.      If 

(a)  Vx6Dx   [IyX   =»   Defined-F:x] 

(b)  D2  fi   Dx 

(c)  Rx  C  R2 

(d)  J  is  an  {x} -precondition  of  Vx€D2   [I2:x    =»    I^sx] 

(e)  K  is  an  {x} -precondition  of 

Vx6D2  VzeR-JJ.-x  A  l2:x  A  z=F:x    =»    02:<x,z>] 
then  F  satisfies  ]f2  with  derived  input  condition  J  A  K. 

Proof:     We  must  show 

Vx€D2[I2:x  A  J:x  A  K:x    =»    02:<x,F:x>]. 

Let  x  be  an  arbitrary  element  of  D2  and  assume  I2:x  A  J:x  A  K:x.  By  condition 
(d)  we  can  infer  Ijtx.  Since  D2  £  Di  we  have  x€D-^  and  by  condition  (a)  we  can 
infer  Defined*F:x.  F:x  is  in  R2  since  FixCR^  Q  R2  by  condition  (c) .  Finally 
by  condition  (e)  we  can  infer  02:<x,F:x>.  QED 

Proposition  4  is  used  when  we  do  not  have  a  specification  for  an  operator  F 
but  its  behavior  is  fully  described  by  the  known  theorems  of  the  DSKB.  Such  a 
situation  arises  for  certain  primitive  functions  of  the  target  language.  These 
are  used  to  specify  and  define  other  functions  but  cannot  themselves  be 
described  in  terms  of  more  primitive  functions.  Their  behavior  in  relation  to 
other  primitive  functions  is  instead  described  by  axioms  (known  theorems) .  All 
that  is  required  for  the  matching  operation  suggested  by  Proposition  4  is  1)  the 
domain  and  codomain  of  F,  2)  conditions  under  which  F  is  defined,  and  3) 
axiomatic  specification  of  its  behavior. 

Example  3.1.2:  The  operator  Cons  is  described  by  its  interaction  with  other 
operators  such  as  First,  Rest,  and  Bag.  Letting  x  vary  over  LIST(]N)  and  a  over 
]N,  the  usual  axioms  include: 

1.  Cons*  [First,  Rest]:x=x 

2.  First -Cons : <a, x>  = a 

3.  Res  t*  Cons :  <a,  x>  =x 
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4.  Defined -Cons :<a,x> 

5.  Bag 'Cons :<a,x>  = Add:<a,Bag:x>. 

we  can  use  Proposition  4  to  show  that  Cons  satisfies  the  following  specifica- 
tion: 

Il2:<a,x>  =  z     such  that  Add:<a,Bag:x>  =  Bag:z 
where    J\  2:  IN  X  LIST(  ]N)     -»    LIST(]N). 

The  input  and  output  domains  of  || 2  and  Cons  coincide.  By  axiom  4  we  implicitly 
have  TRUE  as  input  condition  for  Cons,  therefore  we  can  derive  TRUE  for  J  in 
condition  (d)  of  the  theorem.  Finally  according  to  condition  (e)  we  attempt  to 
find  an   {a ,x} -precondition  of 

V<a,x>€  H  X  LIST(]N)    [TRUE  A  TRUE    =>   Add:<a,Bag:x>  =  Bag: Cons :<a,x>] . 

This  formula  is  easily  shown  valid  by  using  axiom  5  above.  Thus  by  Proposition 
4  we  conclude  that  Cons  satisfies   ]72  with  derived  input  condition  TRUE. 

It  may  be  that  no  single  known  function  satisfies  a  given  specification  but 
that  a  structure  of  known  functions  will  satisfy  it.  If  the  specification 
requests  a  mapping  of  type  D^  X  •  •  •  X  Dm  ->  Rj  X  •  •  •  X  ^  then  a  function  structure 
of  the  form  [f  ■,  ,f  2.  •  •  /fn]  is  required.  A  straightforward  backtracking  algorithm 
for  placing  these  n  functions  can  be  used  to  find  all  potential  structures. 
Once  a  structure  is  found  with  the  correct  input  and  output  types  the  matching 
operation  can  be  invoked  to  verify  satisfaction  of  the  specification. 

Example  _3*A'J3;  Consider  the  specification 

||  :x  =  <a,z>  such  that  x=Cons:<a,z> 
where   TJ":LIST(]N)     -»    ]NXLIST(W). 

Here  a  function  structure  of  the  form  [f1,f2]  is  required.  For  f^  we  might  con- 
sider all  known  functions  mapping  LIST(]N)  to  IN  such  as  First,  Length,  Min, 
etc.  For  f2  we  might  consider  all  mappings  from  LIST(]N)  to  LIST(]N)  such  as 
Rest,  Sort,  etc.  Passing  [First, Rest]  to  the  matching  operations  described  in 
the  previous  section  we  can  derive  x  ^  nil  as  derived  input  condition.  Tne 
derived  input  conditions  for  the  other  potential  structures  are  not  very  weak  so 
they  are  discarded. 
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3. 2  Problem  Reduction  Representations  and  Simple  Divide  and  Conquer  Algorithms 

A  problem  specification  typically  provides  few  indications  of  how  to  go 
about  solving  it.  Rather  than  attempt  to  map  directly  from  the  specification  to 
a  satisfying  program,  our  approach  to  synthesizing  a  divide  and  conquer  algo- 
rithm proceeds  by  enriching  the  specification  with  additional  structure  in  the 
rorm  of  algebras  on  the  input  and  output  domains.  The  construction  of  these 
algebras  is  constrained  not  only  by  each  other  but  also  by  the  input  and  output 
conditions.  The  result  of  this  enrichment  process  is  called  a  problem  reduction 
representation  of  the  original  specification.  A  program  may  then  be  straight- 
forwardly constructed  from  the  components  of  the  representation. 

Let  2    be  a  simple  S-sorted  signature  of  type  <w,§>  where   wES  , 
w  =  w1/w2f  ...,wn,  and  §€S.   A  ^-problem  reduction  representation  (^-PRR)  is  a 
system  ||  =  <E,T,J,P> 
where 

1.  E  is  a  ]>  ~  -algebra  called  the  input  algebra 

2.  T  is  a  ^-algebra  called  the  output  algebra 

3.  J  =  <JS>S  g  s  is  an  S-indexed  family  of  relations  on  E 

(i.e.  Js  C  Es  for  s€S)  called  the  family  of  input  conditions 

4.  p  =  <ps>s€s  *s  an  s"~indexed  family  of  relations  on  EXT 

(i.e.  Pg  C  Eg  X  Ts  f o r  each  s)  called  the  family  of  output  conditions. 

For  each  s€S  let  \\~,   called  a  component  problem,  denote  the  problem  specif ica- 
tion  <Eg,Tg,Jg,Pg>.    ||   will  be  called  the  principal  problem  and  for  each 

s€S-§  JTc  will  be  called  an  auxiliary  problem.      represents  specification 
a       ^        

||  =<D,R,I,0>  if  II  =  II. 

s 

An  S-indexed  family  of  functions  F  =  <fs>s  g  q  satisfies  ^-problem     reduction 

representation  TT  =  <E,T,J,P>  if 

1.  for  each  s€S,  fs  satisfies  J\s  =  <ES,TS,JS/PS>,  and 

2.  F  is  a  L-restricted  homomorphism  from  E  to  T  for  some     relation     L    on 
E  . 

Clearly  if  F  =  <fs>sgs  satisfies  J\   and    M*  represents  Jf  then  f     satisfies  Tf. 

An  S-indexed  family  of  functions  F  =  <fs>sgs  is  called  a  simple  divide    and 
conquer  program  if  f     has  the  form 
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f    :x    =   if 


q:x    -»    h:xfl 
~q:x    -»    CTT*fw*crE:x 
fi. 

We  call  <rE  the  decomposition  operator,  aT  the  composition  operator,  fs  an  auxi- 
liary operator  for  each  s€S-§,  and  h  the  primitive  operator.  The  term  "simple" 
is  used  to  denote  the  restriction  that  f     employs  a  single  pair     of     composition 

and  decomposition  operators.  Our  main  synthesis  task  is  to  construct  a  ^-PRR 
which  represents  a  given  specification  then  construct  a  simple  divide  and  con- 
quer program  which  satisfies  it. 

Theorem  1  characterizes  programs  which  satisfy  a  £-PRR  and  provides  the 
basis  for  the  synthesis  method  presented  in  Section  3.  Most  of  the  conditions 
of  Theorem  1  are  straightforward  requirements  on  the  correctness  of  the  programs 
f  for  each  s€S.  An  exception,  and  perhaps  the  most  interesting  condition,  is 
the  "separability"  condition.  In  words  it  states  that  if  input  Xq  decomposes 
into  subinputs  x-^, . . .  ,xn,  and  Zy  ...,zn  are  feasible  outputs  with  respect  to 
these  subinputs  respectively,  and  z^,...,zn  compose  to  form  Zq  then  zQ  is  a 
feasible  solution  to  input  xn.  Loosely  put:  feasible  outputs  compose  to  form 
feasible  outputs.  It  is  the  principal  link  between  the  algebras  E  and  T,  and 
the  input  and  output  conditions. 

Theorem  1:  (Sufficient  conditions  for  the  existence  of  a  simple  divide  and  con- 
quer solution  to  a  problem  reduction  representation)  Let  ||  =<E,T,J,P>  be  a  j>- 
PRR  where  £  is  a  simple  S-sorted  signature  of  type  <w,§>,  and  let  F  =  <fs>s€s  ^e 
an     S-sorted     family    of  functions.     Let   ^  be  a  well-founded  ordering  on  E    and 

let  0E  and  Op  be  relations  on  ESw  and  TSw  respectively.     If 

(1)  (Specification  of  cr£)    the  decomposition     operator     aE     satisfies     the 
specification 

o-£:x0  =  <x1,...,xn>  such  that  J  :xQ    =>      A     (Jw.  rxj  A  (i  =  §  ^XqJ-x^  )    A 

Up !\Xi  i  •  •  •  f  X_. ^ 

where  o-P:E      -»    Ew 

with  derived  input  condition  KE; 

(2)  (Specification  of  aT)      the     composition     operator     o~T    satisfies     the 
specification 

-39- 


o-T:<zlf...fzn>  =  Zq  such  that  Qr:<ZQ,z1,. .  .  #zn> 
where  Om:'Iw  ->   T 

with  derived  input  condition  TRUE; 

(3)  (Separability  of  P)  the  following  formula  is  valid: 

V<x0,xlf . . .  ,xn>  €  E5*  V<z0/Zi/  ...,zn>€^w 

[crE:x0  =  <x1,...,xn>  A  A  Pw.:<*i'zi>  A  o-T:<z1/.../zn>  =  zQ  =»  P  :<x0,zQ>] 

1  c  n   1  s 

(4)  (Solutions  to  Auxiliary     Problems)     for     each     s6S-§,     fg     satisfies 
il"s  =  <Es'Ts'Js'ps>'* 

(5)  (Structure  of  f  ) 

S 


(5.1)     f   :x    =   if 
§ 


q:x    -»   h:xD 
rT*i. 


~q:x    ->   ovfw,o>:x 


fi 

(5.2)  the  guard  ~q  is  K£, 

(5.3)  h  satisfies  the  specification  <E  ,  T  ,  J  Aq*   P  >r 

§       §       §  § 

(5.4)  the  following  formula  is  valid: 

Vx€E      [J  :x    =*    Defined*q:x]; 
S       § 

then  the  simple  divide  and  conquer  program  F  satisfies  || . 

Proof :  lb  show  that  F  satisfies  J\   we  first  show  that  fs  satisfies  JT  for  each 

s6S.   By  condition  (4)  this  is  so  for  each  s€S-§.  To  show  that  f  satisfies 

§ 

||     =  <E  ,T  , J  ,P  >  we  will  prove 
s         §     §     S     § 

Vx€E     [J  :x    =»    P:<x,f   :x>] 
§       s  § 

by  structural  induction1  on  E  . 

Structural  induction  on  a  well-founded  set  <W,  )•>  is  a  form  of  mathematical 
induction  described  by 

Vx€W  Vy€W[x)-y  A  Q:y    =>    Q:x]    =»    Vx€W  Q:x 
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Let  x  be  an  object  in  E  such  that  J  :x  holds  and  assume  (inductively)  that 

§  § 

j  :y    =>    P:<yff   :y>  holds  for  any  y€E     such  that  x}-y.     From  J  :x  and  condition 
§  §  2  § 

(5.4)    it  follows  that  q:x  is  defined  thus     there     are     two     cases     to     consider: 
q:x  =  TRUE  and   ~q:x  =  TRUE. 

Case  1:  Assume  that  q:x=TRUE  then  f   :x=h:x  by  construction  of  f   .     Furthermore 
§  § 

according     to     condition    (5.3)   we  have  J  :x  A  I'-*    =*>    P  :<x,  h:x>  from  which  we 

easily  infer  P  :<x,  h:x>  or  equivalently  P  :<x,   f   :x>. 
§  §  § 

Case  2:  Assume     that     ~q:x=TRUE     then     f   :x  =crT*fw*aE:x.       We     will     show     that 

P  :<x,f   :x>  by  using  the  inductive  assumption  and  modus  ponens  on  the  separabil- 

ity  condition.     By  condition    (5.2)    ~q  is  K£     so     K£:x=TRUE.        Since     J  :x     also 

holds,  and  o"E  satisfies  its  specification  in  condition   (1),   the  output  condition 
of  aE  also  holds.     Let  o"E:x  =  <x^, . . .  ,xn>.     We  have  for  each  i  6n     Jw>:x^.       Con- 
sider    x,-  for     each     i€n.        If     w.-  ^§  then  by  condition    (4)   we  have  J„  :x,-    =» 
l  —  l  *  v    '  w^      1 

pw.  :<xi'^w  :xi>  an<^  ^  olDta^n  by  modus  ponens  Pw  :<x^,fw.  :x^>.  If  on  the  other 
hand  w*  =  §  then  by  condition  (1)  we  have  Xq^Xj  and  thus  by  our  inductive 
assumption  Jw.  :x^    =»    Pw>  :<x^,fw.  :xj_>.     Again  we  obtain  Pw- :<x^,fw- :x^>  by  modus 

ponens.       By     condition      (2)  we  have  (Xj,:<a^,:<fVf  :xp...,fw  :xn>,z^, . . .,zn>  where 

Om:<f.,  :x-i,...,f,.  :xr>>  =  f   :x.     We  have  now  established  the  antecedent  of     condi- 
1       wl     x  wn     n         § 

tion   (3)   enabling  us  to  infer  P  :<x,  f   :x>. 

We  have  shown  that  for  each  s€s  fs  satisfies  ||  s  =  <ES,TS,JS,PS>.  It 
remains  to  show  that  F  is  a  L-restricted  homomorphism  from  E  to  T  for  some  rela- 
tion L  on  E  .     Let  L  be  KE.      If  x  € E     and  K£:x  holds     then     by     condition     (5.2) 

~q:x  holds  thus  f   :x  =  crT*fw,crp:x.     QED 


In  overall  structure  the  synthesis  method  systematically  attempts  to 
satisfy  the  conditions  of  Theorem  1  more  or  less  in  the  stated  order.  Condi- 
tions (1),  (2),  and  (3)  are  used  to  construct  E  and  T.  Condition  (5.2)  is  used 
to  determine  q.  Finally  condition  (5.3)  is  used  to  construct  h.  The  various 
derived  functions  are  assembled  according  to  the  schema  in  condition   (5.1). 


i.e.,   if  Q:x  can  be  shown  to  follow  from  the  assumption  that  Q:y  holds  for     each 
y  such  that  x}.y,  then  we  can  conclude  that  Q:x  holds  for  all  x. 
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3. 3  Design  Method  for  Simple  Divide  and  Conquer  Algorithms 

The  synthesis  method  described  in  this  section  constructs  a  simple  divide 
and  conquer  algorithm  along  the  lines  suggested  by  Theorem  1.  We  first  describe 
the  method  formally  then  provide  a  detailed  explanation  in  Section  3.4  of  the 
synthesis  of  a  selection  sort  algorithm.  The  reader  may  find  it  useful  to  read 
the  description  and  the  example  in  parallel. 

Let  TYPEBAG (A)  be  the  bag  of  primitive  data  types  whose  product  forms  the 
data  type  A.  For  example, 

TYPEBAG(]N  X  (  W  X  LIST(]N)))  =  {  ]N,  ]N,LIST(  U)  }  . 

Assume  we  are  given  a  specification  ||  =<D,R,I,0>.  The  following  steps  of  the 
synthesis  method  produce  a  ^-problem  reduction  representation  ||  =<E,T,J,P> 
representing  If .  The  first  step  is  to  find  a  suitable  sort  set  S  and  signature 

1.  Determine  a  set  of  sorts  S  and  a  simple  S-sorted  signature  £  of  type  <w,§>. 

One  heuristic  for  determining  S  and  £  is  as  follows.  Let  a  € TYPEBAG (D)  and 
b € TYPEBAG (R)  be  primitive  types  which  are  the  principal  carriers  of  known  alge- 
bras A  and  B  respectively  where  A  and  B  have  the  same  simple  signature.  Let  S 
be  the  sort  set  and  £  be  the  S-sorted  signature  of  A  and  B.  Types  a  and  b  will 
De  called  the  recurrent  types  in  D  and  R  respectively.  Intuitively  the 
recurrent  types  correspond  to  those  inputs  and  outputs  which  will  be  decomposed 
and  composed  respectively.  The  other  inputs  and  outputs  will  remain  unaffected 
by  the  decomposition  and  composition  operators. 

For  example,  suppose  D  =  $i  X  LIST(]N)  and  R  =  BAGS(]N).  According  to  Example 
2.4.1  we  have  algebras  with  the  same  signature  for  LIST(]N)  and  BAG(IN)  -  in 
particular  the  sort  set  S  is  {§,c}  and  the  signature  2    has  type  <c§,§>.   We 
adopt  £  as  the  signature  of  the  algebras  to  be  constructed  on  D  and  R. 

2.  Determine  the  component  problems  TTS  =  <ES,TS,JS,PS>  for  each  s€S. 

Determining  the  principal  problem  J\  is  easy  since  we  want  J\  =  TT;  i.e., 
E  =D,  T  =R,  J   4=*  I,  P  4=»  0.  The  structure  of  the  auxiliary  problems  is 

§  5  S  § 

based  on  the  simplifying  assumption  that  a  simple  known  function  satisfies  each 
auxiliary  problem  (alternatives  are  discussed  in  Section  3.5).  Accordingly,  for 
each  s€S-§,  let  ES=AS  and  TS=BS.     We  select  a  function  fs  from  the  DSKB     such 
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that  fs:Es    ->    Tg,   then  let  Jg:x   <=>  Defined*fs:x  and  Pg:<x,z>   «=»   z  =  fg:x. 

In  the  previous  example  we  have  sort  set  S=  {§,c},     a     signature     with     one 
operator       of       type       <c§,§>,       E    =  $i  X  LIST(]N) ,       T    =Bag(]N)       and     algebras 

A  =  <{]N,LIST(]N)},{Cons}>     and     B  =  <{  ]N,BAG(  IN) } ,  {Add}>.       In       these       algebras 

A„  =  B_  =  IN,     so  we  let  E    =  T    =  ]N.     The  single  operator  ap  in  E  maps  E     into  $F 

i.e., 

0"E:W  X  LIST(W)     ->     ]N  X  (M  XLIST(W)) 
and  the  single  operator  0"m  in  T  maps  T°     into  T  ,   i.e., 

o~T:  K  XBAG(]N)     -»    BAG  (IN). 


lb  determine  the  auxiliary  problem  ||c  we  retrieve  a  known  function  mapping  Ec 
to  T„  ( ]N  to  ]N),  such  as  the  identity  function  Id.  Then  we  can  define  I  :x  4=£ 
TRUE    (i.e.,    Id  is  defined  for  all   inputs)   and  P  :<x,z>   <=>   Id:x  =  z. 


3.  Construct  a  well-founded  ordering  on  E  . 

§ 

Choose  a  known  well-founded  ordering  on  E  .     If  none     is     known     then     con- 

§ 

struct  a  well-founded  ordering  ^  on  the  recurrent  type  of  E  using  Proposition 

1,  then  if  necessary  use  Proposition  2  to  make  it  into  a  well-founded  ordering 
on  E  . 

4.  Construct  the  operators  of  E  and  T. 

There  are  2  alternate  ways  to  finish  the  construction  of  E  and  T;  in  one  we 
construct  E  then  T,  in  the  other  we  construct  T  then  E.  The  important  idea  here 
is  that  once  we  construct  the  first  operator  we  essentially  "solve  for"  the  out- 
put conditions  of  the  other  operator  using  the  separability  condition  of  Theorem 
1.  In  other  words,  the  separability  condition  can  be  likened  to  an  equation  in 
several  unknowns  -  after  plugging  in  a  value  for  all  variables  but  one  we  can 
solve  for  the  value  of  the  one.  The  "unknowns"  are  the  output  conditions  of  the 
operators  o-E,  aT,  and  fs  for  each  s€S-§. 

In  the  following  sequence,  called  track  ET,  we  construct  E  then  T.  The 
difference  between  the  two  tracks  is  this:  the  input  and  output  types  of  the 
operators  have  already  been  determined.  Furthermore,  condition  (1)  of  Theorem  1 
predetermines  some  of  the  input  and  output  conditions  for  0"E.  The  only  other 
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constraint  on  the  operators  is  that  they  satisfy  the  separability  condition.  So 
in  track  ET  we  synthesize  any  function  at  all  for  crE  satisfying  the  input/output 
type  and  condition  (1)  of  Theorem  1  which  should  be  easy  to  do.  The  hard  part 
is  determining  an  output  condition  for  aT  which  satisfies  the  separability  con- 
straint. We  use  the  precondition  engine  to  find  such  an  output  condition  then 
form  a  complete  specification  for  o~T.  Finally,  a  function  is  synthesized  satis- 
fying this  specification.  In  the  other  track,  called  track  TE,  an  operator  o"T 
is  synthesized  satisfying  a  specification  based  on  condition  (2)  of  Theorem  1. 
we  then  derive  an  output  condition  for  crE  required  by  the  separability  con- 
straint and  use  it  to  form  a  complete  specification  for  o"E.  Finally  crE  is  syn- 
thesized. 

ET  4.1  Construct  E 

Construct  a  decomposition  operator  satisfying  the  specification 

crE:x0  =  <xlf...,xn>  such  that  J  :xQ  =*>   A  (Jw.:x_j  A  (Wj=§  =»  xQ^Xj)) 

where  o>:E   -»  Ew 
E  § 

with  derived  input  condition  Ke:xq.  The  specification  is  constructed  from  con- 
dition (1)  of  Theorem  1  and  the  input/output  types  obtained  from  step  2. 
Included  in  the  specification  are  all  elements  of  the  specification  in  condition 
(1)  of  Theorem  1  which  are  known  at  this  point.  After  synthesizing  the  operator 
aE  we  can  define  Oe:<Xq,x^,..  .,xn>  to  be  cte:xq  =  <x-jy. .  .,xn>. 

ET  4.2    Construct  T. 

ET  4.2.1     Derive  the  output  conditions  for  o"T. 

Find  a  {Zq^,  ..  ,,znJ -precondition  Op  of 

V<z0,z1, . . .  ,zn>  €  TSw  V<x0,x1, . . .  ,xn>  €  E§w 

[oE:x0  =  <x1,...,xn>  A     A  Pw.:<Xj,Zj>    =»    P  :<x0,zQ>]  (ET  4.2.1) 

The  derived  precondition  Op  is  an  output  condition  needed     by    crT     in     order     to 
satisfy  the  separability  condition  of  Theorem  1. 

ET  4.2.2     Construct  o-T. 
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Using   the  precondition  Qj.  from  the  previous  step,  we  construct  aT  according 
to  the  specification 

crT:<Zp  . .  «/Zn>  =  Zq  such  that  Gj,:<zn,z, , . . .  ,z  > 

where  o-rr:'Iw    ->   T  . 
T  § 

This  completes  the  description  of  track  ET.     We     now    present     its     alternate     - 
track  TE. 

Track  TE  -  Construct  T  then  E 

TE  4.1     Construct  T 

Construct  the  operator  aT  out  of  known  functions  according  to  the     specifi- 
cation 

(Trj,:<z^, ..  .,zn>  =  Zq  such  that  TRUE 
where  o-,P:Tw    -»    T  . 

All  that  we  need  to  do  here  is  to  construct  a     mapping     from     Tw     to     T  .       This 

specification  is  based  on  the  specification  in  condition    (2)   of  Theorem  1.     Once 
a™      has       been       synthesized       we       can       define       Qji:<Zq,Zw  ...,z n>       to         be 

Cipt  <Zi  r  •  •  •  tzr^  =  z0* 

TE  4.2     Construct  E. 

TE  4.2.1  Derive  output  conditions  for  0"E. 

Find  a  {xq/X^, . • .,xn) -precondition  0£  of 

V<x0/X1/...,xn>€  Ew  V<z0fZ1,...,zn>6T§w 

[.£  Pw.:<xj'zj>  A  o-T:<zlf...,zn>  =  zn  =»  P  :<x0,zn>]    (TE4.2.1) 

Taking  0E  as  an  output  condition  of  aE  enables  us  to  satisfy  the  separability 
condition  of  Theorem  1. 

TE  4.2.2  Construct  E 

Construct  the  operator  o-£  according  to  the  specification 
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crE:x0  =  <x1/...,xn>  such  that  J  :xQ    =»    0^.^,^^ . .  wXn>  A 

(.A    Jw.:xi  A  (wi=S   =*•   Xq^x^) 
j  €n       j     J  J  J 

where  o>:E      -»    Ew 
E     § 

with  derived  input  condition  KE:x.  This  completes  the  description  of  step  4. 

5.  Determine  the  guard  q. 

In  accordance  with  condition  (5.2)  of  Theorem  1  the  guard  ~q  is  simply 
taken  to  be  the  derived  input  condition  KE  returned  by  the  construction  of  o"E. 
We  also  attempt  to  verify  condition  (5.4)  of  Theorem  1  by  deriving  a  {x}- 
precondition  of 

Vx€E  [J  =»  Defined*q:x]. 

Let  Kg  be  the  derived  precondition.  If  PC  is  TRUE  then  condition  (5.4)  has  been 
satisfied.   Otherwise  for  legal  inputs  such  that  J  :x  A  L:x  it  is  possible 

that  the  guard  q:x  is  undefined  thus  f  :x  is  undefined.  We  take  a  simplified 

form  of  J  :x  A  K_:x  as  a  new  input  condition  and  return  to  step  4. 

6.  Construct  the  primitive  operator. 

Construct  an  operator  h  according  to  the  specification 

h:xg  =  z0  such  that  J  :xQ  A  q:xQ  =»  P  :<Xq,zq> 
where  h:E   -»  T  . 

with  derived  input  condition  K^. 

7.  Construct  a  new  input  condition  if  necessary. 

If  h  is  unsatisfiable  or  if  the  derived  input  condition  K^  is  not  TRUE  then 
we  are  not  guaranteed  that  h  will  handle  correctly  all  inputs  which  it  may  be 
required  to  handle.  It  is  necessary  then  to  revise  the  input  condition  and  then 
go  back  and  rederive  the  operators  of  E  and  T,  the  guards,  and  h  in  accordance 
with  the  new  input  condition.  At  this  point  we  have  effectively  derived  a  pro- 
gram satisfying  output  condition  P  with  input  condition 

(Jfi  A  ~q)  V^AqAV.  (3.3.1) 

We  take  a  simplified  form  of  (3.3.1)  as  the  new  input  condition  J  and  return  to 
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step     4.        In     other     words,   formula    (3.3.1)   exactly  describes  the  set  of  inputs 
which  we  know  to  have  solutions  thus  we  take  it  as  our  new  input  condition. 

8.     Assembly  of  a  divide  and  conquer  algorithm. 

Assemble  the  functions  derived  above  according  to  the  schema 


f   :xn    =   if 


q:xn    ->    h:xQ 
:0    ~*    ^T*1 


~q:xn    ->    ovfw,o-p:   x, 


fi. 


The  derived  input  condition  on  this  program  is  J  :xn. 


3.4  Synthesis  of  a  Selection  Sort  Algorithm 
3.4.1  Synthesis  of  Ssort 

Suppose  we  are  given  the  following  specification  for  sorting  a  list  of 
natural  numbers 

Sort:x  =  z  such  that  Bag:x=Bag:z  A  Ordered :z 
where  Sort:LIST(  IN)     -»    LIST(U). 

The  input  domains  and  output  domains  are  both  LIST(IN),  the  input  condition  is 
TRUE  (i.e.,  there  is  none),  and  the  output  condition  is  Bag:x=Bag:z  A 
Ordered :z.     The  steps  of  the  synthesis  method  follow: 

1.  Determine  a  set  of  sorts  S  and  an  S-sorted  signature  £. 

Since  the  input  and  output  types  are  both  LIST(]N)    there  is  an  easy     choice 

of     the     recurrent  type,  namely  LIST(]N).     Several  algebras  are  available  in  the 

D6KB  with  LIST  (IN)   as  carrier;  so  suppose     that     we     select     A  =  <{  ]N,LIST(]N) } , 

{Cons}>.     The  sort  set  of  A  is  S  =  {c,§}  where  A    =LIST(]N),  A    =  ]N,  and  the  sig- 

§  c 

nature  has  type  <c§,§>,  i.e.,  Cons:A~a  ->  A  . 

§ 

2.  Determine  the  component  problems. 

Let  E    =LIST(]N),   T    =LIST(]N),  J     <=*>  TRUE,   P  :<x,z>   «=>     Bag:x=Bag:z     A 
§  §  §  § 

Ordered:z.        In     order  to  determine  the  auxiliary  problem  <EC,TC,JC,PC>  we  first 
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set  E    =  T    =  A    =  U .     We  then  look  for  a  simple  function  from  Ec  to  Tc  and  select 
the  identity  function  Id.     Since  Id  is  defined  for  all  inputs  we  set 

Jc:x0   4=>   TRUE 
Pc:<x,z>   «=>  z=Id:x   <=»  x=z 

so  that  Id  satisfies  <EC,TC, JC,PC>. 

3.  Construct  a  well-founded  ordering  on  E  . 

§ 

Suppose  that  we  do  not  have  a  known  well-founded  ordering  on  E  .     By  Propo- 

S 

sition  1  we  can  construct  one  based  on  a  mapping  from  E  to  ]N.  The  known  func- 

§ 

tion  Length  maps  LIST(U)    to    IN  so  define 

Xq    y  x-i   iff  Length:xQ  >  Lengthrx^. 
By  Proposition  1  <E  ,^>  is  a  well-founded  set. 

4.  Construct  the  operators  of  E  and  T. 

Let  us  follow  track  TE  and  first  construct  T,   then  E. 

TE  4.1  Construct  T 

The  specification  for  o~T  is 

oT:<b,z1> =  z0  such  that  TRUE 
where  aT:U  X  LIST  (IN)     -»    LIST  (IN). 

The  known  function  Cons  has  the  same  type  as  aT  and  we  easily  conclude  then  that 


TE  4.2  Construct  E 

TE  4.2.1  Derive  the  output  specification  of  o"E 

The  output  condition  of  aE  must  satisfy  the  separability    condition     so     we 
set  up  the  problem  of  finding  a   {xQ, a  ^-^-precondition  of 

V<X0,a,x1>6LIST(lN)  X  W  XLIST(]N)    V<z0fb,z1>6  LIST(U)  X  W  XLIST(M) 
[  a=b  A  Bagixj  =Bag:z1  A  Ordered iz-^  A  Cons:<b,Zj>  =  zQ 
=»    (Bag:xQ  =  Bag:zQ  A  Ordered :zQ)] 
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To  construct  this  formula  we  have  made  the  following  substitutions  into  the  for- 
mula schema  (TE  4.2.1): 

1.  replace  w  by  c§ 

2.  replace  E     and  T    by  LIST(]N) 

3.  replace  Ec§  and  T°§  by   ]NXLIST(]N) 

4.  replace  Pc:<a,b>  by  a  =  b 

5.  replace  P  :<x,z>  by  Bag:x=Bag:z  A  Orderedrz 

§ 

6.  replace  o_T:<b,z1>  by  Cons:<b/z1> 
In  Figure  8  the  precondition 

a£Bag:x2  A  Bag:xQ  =  Add:<a/Bag:x1> 
is  derived. 

TE  4.2.2  Construct  E 

Using  the  output  precondition  derived  above,  aE  is  specified  by 

°E:x0  =  <a'xl>  sucJl  tliat  a£Ba9:xi  A  Bag:xQ  =  Add:<a,Bag:x0>  A 

Leng  th :  x  Q>Leng  th :  x  i 
where  crE:  LIST  (]N)     -»    U  X  LIST  ( ]N ) 

In  creating  this  specification  we  have  simplified  in  certain  ways:  1)  since  the 
input  condition  is  TRUE  it  is  omitted,  2)  any  conjunct  which  is  TRUE  is  omitted, 
and  3)  we  replace  Xg^x-^  by  its  definition.  In  Section  3.4.2  we  derive  a  pro- 
gram satisfying  this  specification  with  derived  input  condition  Xg^nil.  For 
now  we  use  the  name  Select  in  place  of  o"E  and  assume  that  it  can  be  synthesized 
with  derived  input  condition  Xg^nil. 

5.     Determine  the  guards. 

The  guard  ~q:xQ  is  simply  the  derived  input  condition  XQ^nil  required  by 
Select.  Consequently  q:xQ  is  xQ=nil.  We  must  also  verify  that  the  guard  q  is 
defined  on  all  inputs  satsifying  the  input  condition.  To  do  so  we  seek  a  {xq}- 
precondition  of 

Vxq€LIST(]N)    [TRUE    =»    Defined :  (x0  =  nil)] 

which  is  easily  shown  to  be  TRUE. 
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Hypotheses:  hi.  a=b 

h2.  Bag:x2  =839:22 

h3.  Ordered :Zj 

h4.  Cons:<b,z1>  =  Zq 


Variables:      {xQ,a,Xi} 
Goal   1: 


<Q1>     Bag:xQ  =Bag:zQ 
R5  +  h4 
<Q1>     Bag:xQ  = Bag:Cons:<b,Zj> 

R5  +  L8 
<Q1>     Bag:xQ  =Add:<b,Bag:z1> 

R5  +  h2,R5  +  hl 
<Q1>     Bag:xQ  =Add:<a/Bag:x1> 
P2 

where  Ql  is  Bag:xQ  = Add:<a,Bag:x2> 


Goal   2: 


<Q2>     Ordered :zQ 
R5+h4 
<Q2>     Ordered: Cons :<b,z1> 


R3  +  L12 


<TRUE>     Ordered :z, 
Pl+h3 


<Q2>     b<Bag:z1 

R5+hl 
<Q2>    ajCBag^j 
P2 

where  Q2  is  a_<Bag:x^ 

Figure  8:  Derivation  of  the  output  condition  of  Select 

6.  Construct  a  primitive  operator. 

The  specification  for  the  primitive  operator  is 


-50- 


h:x0  =  z0  such  that  xQ  =  nil    =$>    (Bag:xn  =  Bag:zQ  A  Ordered  :zQ) 
where  h:LIST(]N)     -»    LIST(]N) 

To  create  this  specification  from  the  specification  schema  for  h  in  Section 
3.3  we  made  the  same  substitutions  as  in  step  4  plus  the  substitution  of  xQ  =  nil 
for  qn.  When  attempting  to  match  known  functions  against  a  specification  such 
as  h  the  simplest  functions  are  tried  first.  In  this  case  the  simplest  of  all, 
Id  works.     Proposition  4  can  be  used  to  verify  that  Id  satisfies  h. 

7.  Construct  a  new  input  condition. 

In  step  6  we  found  that  Id  satisfies  the  specification  for  h  so  no  action 
is  required  here. 

8.  Assembly  of  divide  and  conquer  algorithm. 

Putting  together  all  of  the  operators  derived  above,  we  obtain  the  follow- 
ing selection  sort  program: 


SsortrxQ    =   if 


Xq  =nil    -»    Xq 


x0^nil    -»   Cons*  (id  X  Ssort)  *Select:x0 
fi 

The  derived   input  condition  on  Ssort  is  TRUE. 

3.4.2  Synthesis  of  Select 

In  the  previous  section  we  derived  the  specification 

Select :xq  =  <a,x-^>  such  that  Bag:Xg  =  Add:<a,Bag:x^>  A  a^Bagzx^  A 

LengthrxQ  >  Lengthtx^. 
where  Select: LIST (]N)     ->    UXLIST(]N) 

Intuitively,  Select:xn  splits  xn  into  two  components,  a  and  x-,,  such  that 
together  a  and  Xi  have  the  same  elements  as  xQ  and  furthermore  a  is  no  greater 
than  any  element  of  Xi.  Note  that  Select  as  specified  has  no  input  condition. 
However,  for  input  nil  the  function  is  undefined.  We  will  derive  Xq  ^  nil  as  an 
input  condition  of  Select.     The  synthesis  of  Select  proceeds  as  follows: 
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1.  Determine  a  sort  set  S  and  signature  £ 

The  input  type  is  LIST(]N)  and  the  output  type  is  ]N  X  LIST(]N)  .  We  select 
LIST(]N)  as  recurrent  type  in  both  and  again  choose  algebra 
A  =  <{]N,LIST(]N)  },{Cons}>  in  which  LIST(]N)  is  the  principal  carrier.  As  above 
the  sort  set  is  S  =  {c,§},  A_  =  $i ,   A  =LIST(]N)  and  the  single  operator  symbol 

has  the  type  <c§,§>. 

2.  Determine  the  component  problems. 

Let  E    =LIST(]N),  T    =  3N  X  LIST(]N) ,   J  :xn   <=>  TRUE,  and 
§  §  §     u 

P  :<x0,<afx1»   <=»  Bag:x0  =Add:<a/Bag:x1>  A  a  KBaqix-^  A  Length:xQ  >  Length  Xy 

Let  E„  =A„  =  ]N  and  T„  =A_  =  Tti.     Next  we  select  a  known  function  f_  mapping  E_  to 
T_     and     again     Id  is  the  simpliest  choice.     Let  Jc:xQ  be  TRUE  and  Pc:<Xq,x1>  be 
Xq  =  Id:xj  or  simply  xQ  =  x-^. 

3.  Construct  a  well-founded  ordering  on  E  . 

E  =LIST(]N)  is  made  a  well-founded  set  exactly  as  in  the  previous  example 
by  defining  XqJ-x^  iff  LengthtXQ  >  Lengthrx-^. 

ET  4.     Construct  the  operators  of  E  and  T. 

In  this  example  let  us  construct  E  first  then  T. 

ET  4.1     Construct  crE 

The  decomposition  function  for  Select  must  satisfy  the  incomplete  specifi- 
cation 

°E:x0  =  <u'xi>  SL|ch  that  Length:xQ  >  Lengthix-, 
where  aE:  LIST  (IN)     -»    3NXLIST(]N). 

This  specification  has  been  constructed  according  to  the  specification  schema  in 
step  ET  4.1  of  the  synthesis  method.  We  show  only  the  simplified  result.  In 
constructing  this  specification  we  have  omitted  the  input  condition  (since  it  is 
TRUE)  and  various  output  conditions  which  are  TRUE.  This  practice  will  be  fol- 
lowed in  the  sequel.  A  function  structure  is  needed  here  and  Proposition  4  can 
be  used  to  show  that  [First, Rest]  satisfies  crE  with  derived  input  condition 
XQ^nil.  First,  the  input  and  output  domains  of  [First, Rest]  are  identical  to 
that     for     o~E.       By     Axiom     L6    we     have     x  ^  nil     as  the  domain  of  definition  of 
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[First, Rest] .      In  terms  of  Proposition  4  then  we  have: 
I-^Xq   <=>  Xq  ?  nil 
I2:xQ    <=»   TRUE 
02:<Xq/<u,x1»   «=»   Length:xQ  >  Lengthy. 

According  to  condition   (d)   of  Proposition  4  we  derive  a   {xQ} -precondition  of 

Vx€LIST(]N)    [TRUE    =>    x0^nil] 

which  is  simply  xQ  ^  nil    (called  J  in  Proposition  4).     Finally,  according  to  con- 
dition  (e)   of  Proposition  4,  we  derive  TRUE  as  an   {xQ} -precondition  of 

Vx06LIST(lN)    V<U/X2>€  H  XLIST(IN) 

[x0^nil   A  TRUE  A    [First, Rest] :xQ  = <u,x1>    =»    Length:xQ  >Length:x1]. 

in  Figure  9.     Thus  by  Proposition  4    [First, Rest]   satisfies  o"E  with  derived  input 
condition  xQ^nil  A  TRUE,  or  simply  xQ^nil. 

ET  4.2  Construct  T. 


Hypotheses:     hi.  xQ  ^  nil 

h2.  [First, Rest] :Xq  =  <u,x1> 

h3.  u  =  First:xQ 

h4.  x^  =  Rest:xQ 

Variables:      {xq} 

Goal   1:  <TRUE>     Length :xQ  >  Length :Xj 

R6+h2  +  L7 
<TRUE>     Length*Cons:<u,x1>  >  Lengthy 

R5  +  L15 
<TRUE>     1+ Lengthy  >  Lengthy 

R3+nl 
<TRUE>     1  >  0 
PI 

Figure  9:  Matching    [First, Rest]   with  specification  for  Og. 
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ET  4.2.1  Derive  the  output  condition  of  o~T. 

The  output  condition  of  crT  must  satisfy  the  separability     condition     so     we 
seek  a   {aQ^Q^a-^z^J-precondition  of 

V«a0,z0>/v/<alfz1»6  WXLIST(W))  X  3N  X  ( N  X  LIST(]N) ) 

V<x0/U/x1>6LIST(]N)  X  N  XLIST(U) 

[[FirstrRest]  :xQ  =  <u,x-j>  A  u=v  A  Bagtx-j^  =  Add:<a1,Bag:z1>  A  a-^^Bagtz-^  A 

Lengthy  >  Lengthy    =» 

(Bag:xQ  =  Add:<aQfz0>  A  aQ^<Bag:z0>  A  Length:xQ  >  Length:zQ)]. 

lb  create  this  formula  the  following  substitutions     were     made     on     the     formula 
schema  in  step  ET  4.2.1  of  the  synthesis  method: 

c§  replaces  w 

E    =  LIST  (IN)    and  T    =  ]NXLIST(]N) 

EC=TC=]N 

[First, Rest]    replaces  orE 
Id  replaces  Pc 

BagtXj  =Add:<a1,Bag:z1>  A  a^Bagrz^  A  Length  xx^  >  Length:z, 
replaces  P  :<x.-,z.-> 

In  Figure  10,   the  precondition 

a^<Baqzz^    =»   Add:<v,  Add:<a1,Bag:z1»  =  Add:<a0/Bag:z0>  A 
a0  —  Ba9:zo  A  2  +  Length  :z-j>Length:  zn 

is  derived. 

ET  4.2.2  Construct  o~T. 

We  construct  the  specification 

oT:<v,<a1,z1»  =  <an,zn>  such  that  a^jCBagzz^   =»   a0<Bag:z0  A 

Add:<v,  Add:<a1,Bag:z1»  =  Add:<a0,Bag:zQ>  A  2  +  Lengthtz-j^  >  Length:zQ 

where  aT:  ]N  X  (3N  X  LIST (]N))     -»    ]N    XLIST(]N) 

A  conditional  program,  call   it     Compose,     can     be     constructed     satisfying     this 
specification  with  derived  input  condition  TRUE: 
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Hypotheses:     hi.  [First, Rest] :xQ  = <ufXj> 

h2.  Bagtx-j^  =Add:<a1/Bag:z1> 

h3.  b^KBaqiz^ 

h4.  u  =  v 

h5.  Length tx^  >  Length :z^ 

Variables:      {ayZ^i^Qt^Q) 
Goal   1: 


<Q1>     Bag:xQ  =Add:<a0,Bag:z0> 
R6+hl  +  L7 
<Q1>     Bag:Cons:<u,x1>  = Add:<a0/Bag:zQ> 

R5  +  L8 
<Q1>    Add:<u,Bag:x1>  =Add:<a0,Bag:z0> 

R5  +  h4,   R5  +  h2 
<Q1>     Add:<v,Add:<a1,Bag:z1»  =  Add:<aQ,Bag:ZQ> 

P2 
where  Ql  is  Add:<v,A3d:<alfBag:z-L»  =  Add:<a0,Bag:z0> 


<a0  —  Ba9:zo>     a0<^Bag:zQ 
P2 

Figure  10a:  Derivation  of  output  conditions  for  o*T. 
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Goal   3:  <Q2>     Length  :xQ  >  Length  :zQ 

|R6+hl  +  L7 
<Q2>     Length: Cons :<ufX2>  >  Length :zQ 

R5  +  L15 
<Q2>     1+ Lengthy  >  Length:zn 
R6+h2  +  L19 
<Q2>     1  + Card :Add :<alf Bag :z^>  >  Length:zQ 

R5  +  B6 
<Q2>     1  +  1  +Card:Bag:Z2  >  Length :zQ 

R5  +  L18 
<Q2>     1  +  1  +  LengthiZj  >  Length:zQ 
P2 
where  Q2  is  a-j^Bagtz^    =»    1  +  1  +  Lengthtz-^  >  Length:z0 

Figure  10b:   Derivation  of  output  conditions  for  aT. 


Compose  :<vf<a2/Z^»    —   if 

v  <a±    ->    <v,Cons:<a1/z1»fl 
v^a^    -»    <a1/Cons:<v,Zi» 
fi 

5.  Determine  the  guards. 

The  input  condition  derived  for  aE  is  xQ  ^  nil  which  we  take  as  ~q:x0.  lb 
verify  condition  (5.4)  of  Theorem  1  we  easily  prove  that  ~q  is  defined  on  legal 
inputs.  However,  we  noted  before  that  Select  will  be  undefined  when  its  input 
is  nil,  yet  here  we  are  about  to  use  the  guard  xn  =  nil  on  the  primitive  opera- 
tor. The  next  step  will  reveal  the  need  for  revision  of  the  input  condition. 

6.  Construct  a  primitive  operator. 

The  specification  of  the  primitive  operator  is 
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h:x0  =  <a/x-L>  such  that  x0=nil    =*    Bag:xQ  =  Add:<a/Eiag:x1>  A 
a_<Bag:x^  A  LengthiXg  >  Length:xi 
where  h: LIST (]N)     -»    IN  X  LIST(  U) . 

It  is  easily  shown  that  this  specification  is  unsatisfiable. 

7.     Construction  of  a  new  input  condition. 

Since  the  specification  for  the  primitive  operator  is  unsatisfiable  we  form 
a  new  input  condition  by  constructing  and  simplifying  the  expression 

(TRUE   A  ~(xQ=nil))    V    (TRUE  A  xQ=nil    A  FALSE) 

yielding  Xg^nil.  In  effect  we  exclude  nil  as  a  legal  input  to  Select  and 
return  to  an  earlier  stage  in  the  synthesis  and  rederive  a-£,  aT/  and  q.  In  the 
following  we  retrace  some  of  the  previous  steps: 

4*.     Construct  E  then  T. 

The  input  condition  J  :xQ  is  redefined  to  be  xQ^nil. 


ET  4.1'     Construct  crE 

The  new  specification  for  crE  is 

°E:x0 = <u'xl>  sucn  that  Xq  ^  nil    =»    Lengthrxg  >  Lengthix^  A  x-^  t  nil 
where  o-E: LIST (]N)     -»    IN  X  LIST(  U) . 

We  found  that    [First, Rest]   satisfied  the  earlier  specification  for  aE  so     it     is 
reasonable  to  try  it  again.     This  time  we  have    (in  terms  of  Proposition  4) 

Il:x0^=^x0  ^nil 
I2:xq^=»Xq  7*  nil 

02:<XQ/<a/XjL»^=^  (Length :xq  >  Lengthix-^  A  x-^nil) 

In  satisfying  condition    (d)     of     Proposition     4     we     derive     TRUE     as     an     {xQ}- 
precondition  of 

VxQ€LIST(]N)    [xQ^nil    =>    xQ^nil]. 

In  satisfying     condition     (e)     we     set     up     the     problem     of     finding     an     {xQ}- 
precondition  of 

Vx0€LIST(]N)    VO/X1>€]NX    LIST  ( IN )    [x0^nil   A  a  =First:xQ  A  x2  =Rest:xQ 
=»    Length:xQ  >  Lengthtx-^  A  x-^^nil]. 
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Ihe  precondition  Rest: x0  ^  nil     is     derived     in     Figure     11.       By     Proposition     4 
[First, Rest]   satisfies  crE  with  derived  input  condition  Rest:xn^nil. 

ET  4.2'.     Construct  T. 

Ibis  step  does  not  involve  the  input  condition  so  the  derivation  of  ctt 
proceeds  as  before  -  we  synthesize  the  conditional  program  Compose. 

5'.     Determine  the  guard. 

The  derived  input  condition  on  o-E  is  ResttXQ^nil  thus  q:*o  *s 
Rest:xQ=nil.  In  Figure  12  we  verify  that  q  is  defined  when  the  input  condition 
(xQ^nil)   holds  by  deriving  TRUE  as  a   {xn} -precondition  of 

VxQ€LIST(]N)    [x0^nil    =$■   Defined:  (Rest: x0  =  nil)]. 

6'.  Construction  of  a  primitive  operator. 

The  new  specification  for  the  primitive  operator  is 


Hypotheses:     hi.   xQ  ^  nil 

h2.   First:xn  =a 
h3.   Rest:x0  =  x-^ 

Variables:      {xn} 

Goal   1:  <TRUE>     Length :xn  >  Length :x-^ 

(see  derivation  in  Figure  9) 

Goal   2:  <Rest:xn  ^  nil>     x-^  ?  nil 

R5+h3 
<Rest:xQ  ^nil>  Rest:xQ^nil 
P2 

Figure  11:  Matching    [First, Rest]   with  specifications  for  aE< 


iypotheses:  hi.   xQ  ^  nil 

/ariables:    {} 

3oal   1:  <TRUE>     Defined: (Rest :xQ  = nil) 

^^  ^-"^A^^  ^R3  +  L3,   Rl 
<TRUE>     Defined:  Rest  :xQ  <TRUE>     Defined  mil 

R3  +  L5  Pl  +  Ll 

<TRUE>  x0  ^  nil 
PI  +  hi 

Figure  12:   Verifying  the  guard  in  Select. 


h:x0  =  <a/x1>  such  that  Rest:x0=nil    =^   Bag:xQ  =  Add:<a,Bag:x1>  A 
a<Bag:xi    A  Length:xQ  >  Lengthy 
where  h: LIST (]N)     -»    UXLIST(IN). 

he  function  structure   [First ,Rest]    is  easily  found  to  satisfy     this     specif ica- 
:ion  as  follows:  Again  in  terms  of  Proposition  4  we  have: 

2:xo   4=t>  Rest:Xg=nil 

i2:<XQ,<a,x1»   <=»  Bag:xQ  =Add:<a,Bag:x1>  A 
a<^Bag:xi    A  Length:xQ  >  Length:x^ 

•j^Xq   4=>  Xg^nil    (by  Axiom  L6) 

o  satisfy  condition    (d)   of  Theorem  1,   TRUE  is  derived  as     an     {xQ} -precondition 
f 

Vx  €  LIST (IN)  [Rest :xQ  =  nil    =»    xQ^nil] 

i  Figure  13.     Finally,   to  satisfy  condition   (e) ,  we  set  up  the  problem  of  f  ind- 
ig  a  {xq} -precondition  of 

''<x0,<a1,x1»€LIST(]N)  X     (3N  XLIST(]N)) 

["RUE  A  Rest:x0=nil   A  First:xQ=a1  A  Rest:x0=x1 

»   Bag:xQ  =  Add:<a,Bag:x1>  A  a_<Bag:x2  A  Length :Xq  >  Length :Xj] . 

le  precondition  TRUE  is  derived  in  Figure  14.       Finally     by     Proposition     4    we 
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Hypotheses:  hi.  Rest:xQ=nil 

Variables:    {} 

Goal   1:  <TRUE>     xQ ^ nil 

R3  +  L5 
<TRUE>     Defined* Rest :Xq 
R5+hl 
<TRUE>     Defined :nil 
PI  +  L1 

Figure  13:  Matching    [First, Rest]   with  the  specification  for  h. 
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Hypotheses:     hi.  Rest:x0=nil 

h2.  [First,Rest] :Xq  =  <a,X2> 

h3.  First:x0  =a 

h4.  Rest:x0  =  x^ 

Variables:    {xQ} 

Goal   1: 


<TRUE>     Bag:xQ  = Add:<afBag:x1> 
R6+h2  +  L7 
<TRUE>     Bag:Cons:<a/x1>  = Add:<a,Bag:x1> 

R5  +  L8 
<TRUE>     Add:<a/Bag:x1>  = Add:<afBag:x1> 
PI  +B1 


<TRUE>     a^Bag^ 
R5  +  h4 
<TRUE>     a  <^Bag:Rest:x0 
R5  +  hl 
<TRUE>     a  <  Bag  mil 
R5  +  L20 
<TRUE>  a  <0 
PI  +B2 


Goal   3:  <TRUE>     Length  :xQ  >  Length :Xi 

R6+h2  +  L7 
<TRUE>     Length :Cons:<a,x1>  >  Length :x-^ 

R5  +  L8 
<TRUE>     1  + Lengthy  >  Lengthy 

R3+nl 
<TRUE>     1  >  0 
PI 

Figure  14:   Verifying  the  match  of    [First, Rest]   with  h 


conclude     that     [First,     Rest]     satisfies     h     with       derived       input       condition 
Rest:x0=nil   A  TRUE  A  TRUE  or  simply  Rest:x0=nil. 
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7'.  Derivation  of  a  new  input  condition. 

Since  we  constructed  an  operator  satisfying  specification  h     this     step     is 
bypassed . 

8'.     Construction  of  a  divide  and  conquer  algorithm. 

The  functions  derived  above  are  assembled  into  the  following  program: 


Select:xQ    —   if 


fi 


Rest:xQ=nil    -»    [First, Rest] :xQ    0 

Rest:x0^nil    ->   Compose*  (Id  X  Select)  ♦  [First ,Rest]  :xQ 


The  derived   input  condition  on  Select  is  XQ^nil    (J  ).     The     complete     selection 
sort  program  synthesized  in  the  above  examples  is  listed  in  Figure  15. 


Ssort:xn    —   if 


Xq  =  nil    -»   Xq 


x0^nil    -»   Cons*  (id  X  Ssort) 'Select :x0 
fi 

Select:x    =   if 

Rest:x=nil  -»    [First, Rest]  :x    Q 

Rest :x  j*  nil  ->   Compose*  (Id  X  Select)  •  [First, Rest]  :x 
fi 

Compose  :<V2*<v2'Z»    =   if 

vllv2    ~*    <v1,Cons:<v2/Z»    fl 
vl^v2    ~*    <v2/Cons:<v1,z» 
fi 

Figure  15:     A  Selection  Sort  Program 
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3. 5  Remarks  on  the  Synthesis  Method 

For  the  sake  of  simplifying  the  presentation  we  have  placed  a  number  of 
restrictions  on  the  synthesis  method.  First,  we  only  consider  algebras  E  and  T 
with  a  single  operator,  thus  the  term  "simple  divide  and  conquer  algorithms".  It 
is  not  hard  to  relax  this  constraint  but  the  analogue  of  Theorem  4  becomes  more 
complex.  Second,  we  assume  that  the  auxiliary  problems  are  simply  solved  by 
primitive  functions  in  the  target  language.  A  design  method  can  be  devised 
which  allows  the  synthesis  of  nonprimitive  auxiliary  functions  in  the  following 
way.  The  essence  of  the  design  method  in  Section  3.3  is  the  use  of  the  separa- 
bility condition  to  solve  for  the  output  conditions  of  either  crE  or  aT.  We  use 
it  to  set  up  a  precondition  problem  by  assuming  simple  solutions  for  the  auxili- 
ary problems  and  for,  say,  crE,  then  we  derive  output  conditions  for  crT.  The 
separability  condition  of  Theorem  1  can  be  likened  to  a  linear  equation  in 
several  variables.  We  plug  in  simple  values  for  all  but  one  variable  x  then 
solve  for  x.  We  could  just  as  well  plug  in  simple  decomposition  and  composition 
Dperators  and  solve  for  the  output  conditions  of  the  auxiliary  problems.  Third, 
we  assume  that  there  is  only  a  single  recurrent  type:  i.e.,  that  only  one  of  the 
parameters  to  a  divide  and  conquer  algorithm  will  be  decomposed.  It  is  not  hard 
to  relax  this  restriction  however  the  decision  about  which  parameters  to  decom- 
pose is  not  well-motivated  at  present  (relying  on  rather  weak  heuristics) . 

We  now  relate  our  synthesis  method  with  previous  work  on  deductive  program 
synthesis.  Suppose  the  user  supplies  a  specification  ||  =<D,R,I,0>.  The  deduc- 
tive approach  to  program  synthesis  [16,17,4]  seeks  to  extract  a  program  f  from  a 
:onstructive  proof  of  the  theorem 

Vx€D  3z€R  [I:x  =*  0:<x,z>]  (3.5.1) 

Iheorem  proving  techniques,  more  or  less  adapted  to  the  special  demands  of  pro- 
gram synthesis,  are  used  to  prove  the  theorem  constructively.  We  advance  this 
approach  in  two  ways.  First,  our  definition  of  the  program  synthesis  problem  is 
slightly  more  general.  We  seek  to  extract  a  program  f  from  a  constructive 
derivation  of  an  {x}-precondition  of  (3.5.1).  The  resulting  precondition  is  the 
derived  input  condition.  With  this  approach  it  is  easier  to  create  specifica- 
:ions  because  we  are  no  longer  required  to  completely  specify  the  input  condi- 
:ion.  It  also  facilitates  top-down  problem  decomposition  because  the  decom- 
position process  is  not  obliged  to  create  complete  specifications  for  subprob- 
.ems.  Second,  rather  than  rely  on  general  theorem  proving  techniques  we 
emphasize  the  use  of  special  purpose  program  synthesis -oriented  techniques, 
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specifically  the  design  methods.  The  design  method  for  simple  divide  and  con- 
quer algorithms  is  based  on  Theorem  1  but  it  also  embodies  the  procedural 
knowledge  needed  to  apply  it.  Viewed  as  a  theorem  proving  tool  it  seeks  to 
exploit  special  structure  in  the  specification.  Specifically,  it  seeks  to 
decompose  the  problem  structure  with  respect  to  the  separability  condition  of 
Theorem  1.  We  are  currently  developing  analogous  design  methods  for  other 
classes  of  algorithms. 
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4.     Further  Examples 

In  this  section  we  derive  three  other  sorting  algorithms  whose  structure  is 
that  of  divide  and  conquer.  These  algorithms  are  all  constructed  from  the  same 
specification  but  their  design  diverges  when  distinct  choices  are  made  at  cer- 
tain steps  in  the  synthesis  method. 

4.1  Synthesis  of  an  Insertion  Sort 

4.1.1  Synthesis  of  Isort 

The  synthesis  of  an  insertion  sort  and  a  selection  sort  are  similar.  The 
synthesis  process  diverges  at  Step  4  -  the  selection  sort  follows  track  TE, 
insertion  sort  follows  track  ET.  Intuitively,  selection  sorts  make  use  of  a 
simple  composition  operator  and  a  somewhat  complex  decomposition  operator 
whereas  insertion  sorts  make  use  of  a  simple  decomposition  operator  and  a  com- 
plex composition  operator.  Again  the  initial  specification  for  sorting  a  list 
of  natural  numbers  is 

Sort:x  =  z  such  that  Bag:x=Bag:z  A  Ordered:z 
where  Sort :  LIST (H)     ->    LIST(]N). 

Isort  is  synthesized  as  follows  with  some  details  omitted  for  brevity. 

1,2,3.     Determine  a  sort  set,  signature,  component  problems,  and  a     well-founded 
ordering. 

As  in  Ssort  let  S=  {c,s*},  let  £  be  a     simple     S-sorted     signature     of     type 

<c§,§>.     and     let     E    =LIST(]N),     T    =LIST(U),     J  :x   <=>   TRUE,  and  P  :<x,z>   «=> 

§  §  §  § 

Bag:x=Bag:z  A  Ordered  z. 

Also  let  Ec  =  ]N,  Tc  =  $i ,  fc:x  =  x,  and  thus  again  Jc:x  «=>  TRUE,  Pc:<x,z> 
«=»  x  =  z. 


Define  *n^xl  ^Y  Length :xQ>Length:x2« 
At  step  4  the  synthesis  process  follows  track  ET. 

ET  4.1  Construct  E. 

The  decomposition  operator  a£  for  Isort  has  the  specification 
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cte:Xq  =  <a,x-j>  such  that  Length:x0>Length:Xi 
where  o-E:  LIST  (IN)     ->    WXLIST(U). 

In  constructing  this  specification  we  have  omitted  the  input  condition 
since  it  is  TRUE  and  various  output  conditions  which  are  TRUE.  This  practice 
will  be  followed  in  the  sequel.  The  construction  [First, Rest]  is  easily  shown 
to  satisfy  this  specification  with  derived  input  condition  xQ^nil.  (See  the 
analogous  matching  process  in  Figure  9) . 

ET  4.2     Construct  T. 

ET  4.2.1     Derive  output  conditions  of  o~T. 

The  output  condition  of  o~T  is  obtained  by  deriving  a  {z0,b,z-, } -precondition 
of 

V<z0/<b,z1»€LIST(]N)  X  (JN  XLIST(IN))    V<xQ,<a/x1»€  LIST(  ]N)  X  (U  XLIST(U)) 
[  [First  /Rest]  :xQ  =  <a,xA>  A  a=b  A  Bagrxj  =  Bagrz^  A  Orderedtz-^ 
=»    Bag:xQ  =  Bag:zQ  A  Ordered :zQ]. 

The  precondition 

Ordered :z,    =^   Add:<b,Bag:z,>  =  Bag:zQ  A  Ordered :zQ 

is  derived   in  Figure  16. 

ET  4.2.2     Construct  T 

Using  the  precondition  derived  in  the  previous  step  we  create  the  specifi- 
cation 

o-T:<b,Z2>  =  Zq  such  that  Orderedrz-^    =»   Add:<b,Bag:z-,>=Bag:zn  A  Ordered:z0 

where  o"T:]N  X  LIST  (U)     ->    LIST(]N). 

A  program  called   Insert  is  synthesized  in  the  following  section  which     satisfies 
this  specification. 

5.     Determine  the  guard. 

The  guard  ~q:x«  is  simply  the  derived  input  condition  XQ^nil  on  Og.  To 
verify  that  q  is  defined  on  legal   inputs  we  easily  can  show  that 

Vx  €  LIST (H)  [TRUE    =»    Def ined:  (x  =  nil)  ] 
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Hypotheses:     hi.  [First, Rest]  :xQ  =  <a,x-L> 

h2.  a  =b 

h3.  Bagzx^  =  Baq-.z-^ 

h4.  Ordered :z^ 

Variables:      {b,zn,z^} 

Goal   1:  <Q>     Bag:xQ  =  Bag:zQ 

R6  +  hl  +  L7 
<Q>     Bag:Cons:<afX2>  =  Bag:ZQ 

R5  +  L8 
<Q>     Add:<a,Bag:x>  =  Bag:zn 

R5  +h2 
<Q>     Add:<bfBag:z1>  =  Bag:zQ 
P2 
where  Q  is  Ordered:z-,    =>   Add:<b,Bag:z-,>  =  Bag:zQ 


Goal   2:  <Ordered:z^    =»    Ordered :zQ>  Ordered :Zq 

P2 


Figure  16:   Derivation  of  Output  Conditions  for  the  Composition  Operator  of  Isort 


is  valid. 

6.  Construct  the  primitive  operator. 

The  primitive  operator  has  specification 

h:xQ    =    Zq  such  that  xQ=nil    =»    (Bag:xQ  =  Bag:zQ  A  Ordered :zQ). 
where  h:LIST(]N)     -»    LIST(]N). 

As  in  the  synthesis  of  Ssort  we  can  show  that  Id  satisfies  h. 

7.  Construct  new  input  condition. 

Since  we  constructed  an  operator  satisfying  the  specification     for     h     this 
step  is  bypassed. 
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8.  Construction  of  the  divide  and  conquer  algorithm. 

Putting  together  the  operators  derived  above  we  obtain 

Isort :x  =  if 

x  =nil  ->  x  D 

X?*  nil    -»    Insert*  (Id  X  Isort)  •  [First, Rest]  :x 
fi. 

The  derived  input  condition  on  Isort  is  simply  TRUE. 

4.1.2  Synthesis  of  Insert 

The  following  specification  for  Insert  was  derived   in  the     preceeding     sec- 
tion 

Insert:<a0,XQ>  =  Zq  such  that  Ordered:x0    =»   Bag:zQ=Add:<a0,Bag:x0>  A  Ordered:z0 

where  Insert:  ]N  X  LIST  (]N)     ->    LIST(]N). 

The  task  of  Insert  is  to  place  a  number  in  an  ordered  list  such  that  the  result- 
ing list  is  ordered.     The  synthesis  of  Insert  proceeds  as  follows. 

1,2     Determine  a  sort  set,  signature,  and  component  problems. 

Choices  like  those  made  in  Ssort,  Select,  and   Isort  can  be     made     here     for 

Insert    with     the     result     S={c,§},     £     is     a  simple  S-sorted  signature  of  type 

<c§,§>, 

E    =  3N  X  LIST(U) 
§ 

T    =LIST(]N) 

J  :<aQ,xQ>   4=»  Ordered  :Xq 

P  :«a0,x0>,ZQ>   <=»  Bag:zQ  =  Add:<a0,Bag:xg>  A  Ordered:x0, 

Ec  =  U  ,  and  Tc  =  2i . 
Again  we  find  Id:Ec    ->   Tc  so  let 
Jc   «=»  TRUE, 


Pc:<a1,b>   4=^  a-j=b,  and 


fc    -   Id. 


3.     Determine  a  well-founded  ordering  on  E  , 
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Using   Propositions  1  and  2,  we  can  construct  a  well-founded  ordering  on  the 
input  type    ]NXLIST(]N)   defined  by 

<aQ,Xg>    y   <a^,x^>  iff  Length:xn  >  Lengthrx-^. 

TE  4.     Construct  T  then  E 

TE  4.1     Construct  T. 

The  composition  operator  of  Insert  has  partial  specification 

o_T:<b/z1>  =  zQ  such  that  TRUE 
where  crT:]N  X  LIST (U)     -»    LIST(]N) 

The  primitive  operator  Cons  is  easily  shown  to  satisfy  this  specification. 

TE  4.2     Construct  E. 

TE  4.2.1     Derive  output  conditions  for  crE. 

The  output  conditions  of  o~E     are     found     by    deriving     a     {a0,XQ,a-,  ,a2,x2}- 
precondition  of 

V«a0,x0>falf<a2,x2»6  (IN  XLIST(]N))  X  IN  X  (  N  X  LIST(]N) ) 
V<z0,b,z1>€LIST(]N)  X  IN  XLIST(]N) 

[a^  =  b  A  Bagrz^  =  Add:<a2,Bag:x2>  A  Orderedtz-^  A  Cons:<b,Z2> = Zq 
=»   Bag:ZQ  =  Add:<an,Bag:xn>  A  Ordered :zQ]. 

The  derivation  in  Figure  17  yields  precondition 

Add:<alfAdd:<a2,Bag:x2»  =  Add:<a0,Bag:xn>     A     ai£a2     A     a1<^Bag:x2. 

TE  4.2.2     Construct  E. 

We  construct  specification 

°E:<a0,x0>  =  <al,<a2'x2>>  suc^  that  Length  :x0>Length:x2  A 

Add:<alfAdd:<a2,Bag:x2»  =  Add:<aQ,Bag:xn>  A  ai  <.a2  A  a,j<Bag:x2 

where  o-£:  IN  X  LIST  (IN)     -»    ]N  X  ( IN  X  LIST(  ]N) )  . 

A  simple  conditional  program  called  Decompose  is  easily  constructed  according  to 
this  specification  with  derived   input  condition  xQ^nil: 

-69- 


Hypotheses:  hi.  a-j=b 

h2.  Bag : Zy&5d:<a 2 ,   Bag:x2> 

h3.  Ordered :z^ 

h4.  Cons:<b,z-L>  =  z0 

Variables:      {a0,XQ/a1,a2/X2} 

Goal   1: 


Goal   2: 


<Q>     Bag:zQ  =Add:<aQ/Bag:x0> 
R5  +  h4 
<Q>     Bag : Cons :<b,Z2>  =  Add:<a0,Bag:x0> 

I  R5  +  L8 
<Q>     Add:<bfBag:z1>  =  Add:<a0,Bag:x0> 
I  R5  +  h2 
<Q>     Add:<alrAdd:<a2/Bag:x2»=Add:<aQfBag:xQ> 

P2 
where  Q  is  Add:<a^,Add:<a2fBag:x2»=Add:<aQ,Bag:xQ> 

<Q3>     Ordered :zq 

R5  +  h4 
<Q3>     Ordered: Cons :<b/z1> 

R3  +  L12,   Rl 


1 
Pl+h3 


<Q3>     b^Bag^  <TRUE>  Ordered  :z 

R5+hl,   R5+h2 
<Q3>     ax  <  Add:<a2/Bag:x2> 


R3+B3,   Rl 


<Q1>     a1<a2  <Q2>     a1<Bag:x2 

P2  P2 

where  Ql  is  ai_<a2/  Q2  is  a-j^Bag^  and  Q3  is  Ql  A  Q2 

Figure  17:   Derivation  of  Output  Conditions  for  Decomposition  Operator  in  Insert. 


-70- 


Decompose :<a0,XQ>    ■   if 

aQ_<  First:xQ    ->    <a0,<First:xQ,Rest:x0»    0 
aQ2 First:xQ    ->    <First:xQ,<a0,Rest:xQ» 
fi. 

5.  Determine  the  guard. 

The  input  condition  on  orE  is  xQ^nil  thus  q:xQ   <=»  xn=nil.     Tb  verify  that 
q  is  defined  whenever  the  input  condition  holds  we  easily  prove  that 

V<a>x>€  H  X  LIST (]N)  [  Ordered :x    =»    Def ined:  (x  =  nil)    ]. 

6.  Construct  the  primitive  operator. 

The  primitive  operator  must  satisfy 

h:<a0,XQ>  =  z0  such  that  xQ  =  nil   A  Ordered :xQ    =£• 
Bag:ZQ  =  Add:<aQ,Bag:x0>  A  Ordered:z0 
where  h:]N  X  LIST (]N)     -»    LIST(IN). 

It  is  easily  shown  that  the  operator  Cons  satisfies  this  specification. 

7.  Construction  of  a  new  input  condition. 

Since  Cons  has  been  found  to  satisfy     the     specification     h     this     step     is 
bypassed . 

8.  Final  assembly  of  the  divide  and  conquer  algorithm. 

Putting  together  the  operators  derived  above  we  obtain 


Insert:<aQ,xn>    =  if 

x0=nil    -»   Cons:<a0,x0>    0 

XQ^nil    -»   Cons*  (Id  X  Insert)  • Decompose :<a0,XQ> 
fi. 

with  derived   input  condition  TRUE.     The  completed  insertion  sort  algorithm  Isort 
is  given  in  Figure  18. 
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Isort:x    —   if 

x  =  nil    ->   x   D 

x^nil    -»    Insert*  (Id  X  Isort)  •  [First , Rest]  :x 
fi 


Insert: <a,x>  =  if 

x=nil  -»  Cons:<a,x>  Q 
x  ^  nil  -»  Cons*  (Id  X  Insert)  'Decompose :x 
fi 


Decompose :<aQ,x0>  —   if 

a0_<First:x0    ->    <aQ,<First:xQ,Rest:x0» 
a0  — First:x0    ~*    <First:xQf<a0fRest:x0» 
fi 

Figure  18.     Complete  Insertion  Sort  Algorithm 


4.2  Synthesis  of  a_  Merge  Sort  Algorithm 

4.2.1     Synthesis  of  Msort 

Again  we  start  with  specification 

Sort:x  =  z  such  that  Bag:x=Bag:z  A  Ordered  :z 
where  Sort:LIST(]N)     -»    LIST(U). 

The  synthesis  of  a  mergesort   (and  a  quicksort)   distinguishes  itself     from     Isort 
and  Ssort  immediately  in  the  choice  of  signature. 

1.     Choose  a  sort  set  and  signature. 

As  before  LIST(]N)    is  the  only  choice  for  recurrent  type  on  both  the     input 
and         output         domains.  Suppose         however         we         choose       the       algebra 
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B  =  <{LIST(  IN) },  {Append} >  which  has  sort  set  S=  {§}  and  a  simple  S-sorted     signa- 
ture of  type  <§§,§>.      I.e.,   Append :B    XB      H>    B   . 

§        §  § 

2.  Determine  the  component  problems. 

Let  E    =LIST(U),   T    =LIST(]N),   J    =  TRUE,   and   P   :    <x,z>    4=»   Bag:x=Bag:z   A 
§  §  §  § 

Ordered :z.     There  are  no  auxiliary  problems. 

3.  Determine  a  well-founded  ordering  on  E  . 

§ 

Again  we  define  Xq^-x^  by  Length :xn  >  Length ix^  as  an  appropriate  well- 
founded  ordering  by  Proposition  1. 

ET  4.  Construct  E  then  T. 

Mergesort  differs  from  quicksort  in  following  track  ET  rather  than  TE.  In 
other  words  mergesort,  like  insertion  sort,  uses  a  simple  decomposition  operator 
and  a  complex  composition  operator  whereas  the  reverse  holds  for  quicksort. 

ET  4.1  Construct  E. 

After  instantiating  and  simplifying  the  schematic  specification  in  step  ET 
4.1  of  the  synthesis  method  we  obtain 

°E:x0  =  <xl'x2>  suc^  that  Length :xQ>Length:x-^  A  Length  :xn>Length:x2 
where  a£: LIST (U)     -»    LIST(]N)  X  LIST(]N)  . 

In  Example  3.1.1  we  showed  that  the  primitive  operator  Listsplit  satisfies     this 
specification  with  derived  input  condition  Length:xn>l. 

ET  4.2    Construct  T. 

ET  4.2.1     Derive  output  conditions  for  Op. 

The  output  condition  of  the  composition  operator  is  found  by  deriving  a 
{zn,z-]yZ2}-precondition  of 

V<z0/Z1,z2>€LIST(lN)  XLIST(W)  XLIST(JN) 

V<X0/X1,X2>€LIST(]N)  XLIST(U)  XLIST(IN) 

[Length :x-^  =  Length :xn  div  2  A  Length :x2  =  (1  +  Length:xQ)   div  2  A 

Append  :xq  =  <x-^,x2>  A  Length :xQ>Length:x,    A  Length:   xn>Length:x2  A 
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Bagrx^  =  Bag:z1  A  Ordered :Zj  A  Bag:x2  =  Bag:z2  A  Ordered :z2 
=»   Bag:xQ  =Bag:zQ  A  Ordered :zQ]. 

The  precondition 

Orderedrz-^  A  Ordered:z2    =»    (Union:<Bag:zlfBag:z2>  = Bag:zQ  A  Ordered:zQ) 

is  derived  in  Figure  19. 

ET  4.2.2     Construct  T. 

Instantiating  the  above  output  condition  in  the  schema  ET  4.2.2  we  obtain 
the  specification 

crT:<zlfz2>  =  z0  such  that  Orderediz-^  A  Ordered:z2   =» 

Union: <Bag:Z2f Bag :z2>  = Bag :Zq  A  Ordered:zQ 

where  orT:  LIST  (]N)  X  LIST  (]N)     -»    LIST(U). 

In  Section  4.2.2  we  derive  a  program  called  Merge  satisfying  this  specification. 

5.  Determine  the  guards. 

The  guard  ~q  is  simply  Length :xQ  >  1  -  the  input  condition  on  crE.  Negat- 
ing, we  obtain  q:x  4=>  Length:x_<  1.  It  is  easily  shown  that  q  is  defined  on  all 
legal   inputs. 

6.  Construct  the  primitive  operator. 

The  primitive  operator  has  specification 

h:x  =  z  such  that  Length:x<^l    =»   Bag:x=Bag:z  A  Ordered :z 
where  h:LIST(]N)     -»    LIST(]N). 

The  identity  operator  Id  is  easily  shown  to  satisfy  this  specification. 

7.  Construct  a  new  input  condition. 

This  step  is  skipped  since  an  operator  has  been  found  which  satisfies  the 
specification  h. 

8.  Construction  of  the  divide  and  conquer  algorithm. 
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Hypotheses:      1.  Append :  <x-l,x2>  =  xQ 

2.  Lengthy  =  Length:xQ  div  2 

3.  Length :x2  =  (1  +  Length :Xq)   div  2 

4.  Length :Xq  >  Length ix-^ 

5.  Length:xn  >  Length:x2 

6.  BagiXj  =  Bagzz-^ 

7.  Ordered  :z-, 

8.  Bag:x2  =  Bag:z2 

9.  Ordered  :z2 

Variables:      {zn,ZpZ2} 

Goal   1:  <Q>     Bag:xQ  =  Bag:zQ 

R5  +  hl 
<Q>     Bag:^pend:<x1/X2>  =  Bag:zQ 
R5  +  L9 
<Q>     Union:  <Bag  :xlfBag  :x2>  =  Bag  :zQ 

R5  +  h6,   R5+h8 
<Q>     Union:<Bag:zlfBag:z2>  =  Bag:zQ 
P2 
where  Q  is  Ordered:z-,    A  Ordered:z2    =»    Union:<Bag:zlfBag:z2>  =  Bag:zQ 

Goal   2:  'COrdered^  A  Ordered :z2   =»   Ordered :zQ>  Ordered :Zq 

P2 

Figure  19:     Derivation  of  output  conditions  for  Merge. 


Assembling  the  operators  derived  above  we  obtain  the  program 

Msort:x    =   if 

Length  :x_<l    ->    x   0 

Length:x  >  1    -»   Merge*  (Msort  X  Msort)  *Listsplit:x 
fi 

The  derived   input  condition  on  Msort  is  TRUE. 
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4.2.2  Synthesis  of  Merge 

In  the  previous  section  we  derived  the  following  specification  for  a  compo- 
sition operator  which  will  be  called  Merge. 

Merge: <Xq, x' 0>  =  Zq  such  that  Ordered:xn  A  Ordered  x'n    =#• 
Union:<Bag:xQfBag:xl0>  =  Bag:zn  A  Ordered:z0 
where  Merge: LIST (]N)  X  LIST (]N)     ->    LIST(]N). 

A  divide  and  conquer  algorithm  for  Merge  is  synthesized  as  follows. 

1.  Determine  sort  set  and  signature. 

There  is  only  one  choice  of  recurrent  type  in  both  the  input  and  output 
domains  -  namely  LIST(IN).  As  before  we  obtain  sort  set  S=  {c,§}  and  signature 
£  of  type  <c§,§>  from  the  algebra  A  =  <{  ]N,LIST(]N) } ,  {Cons}>. 

2.  Determine  the  component  problems. 

Let 

E    =  LIST(]N)  XLIST(]N) 

T    =LIST(]N) 

J  :<Xq,x'q>   ^=»  Ordered :xq  A  Ordered :x'n 

P  :«Xq/x'q>/Zq>   4=>  Union: <Bag:xQf Bag :x ' q>  =  Bag :Zq  A  Ordered:zQ 

EC=AC=]N 
TC=AC=]N 

again  we  find  Id:Ec    -»    Tc  so  let 

Jc:x   <=>  TRUE 
Pc:<x,z>   4=^  x  =  z 

fc    -   Id. 

3.  Determine  a  well-founded  ordering  on  E  . 

Since  E    =LIST(]N)  XLIST(]N)   we  can  construct  a     well-founded     ordering     by 

seeking     a     mapping     from     LIST ( Tti )  X  LIST (]N)      to      H  X  3N-     The  function  product 
Length  X  Length  suffices  so  we  define 

<Xq,x'q>  J-<x1/x'1>  iff  Length  X  Length: <Xq,x'q>  >2  Length  X  Length :<x1,xl1> 
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where  <i0,i'0>  >2  <ii/i'i>  iff  io>il  or    ^{f^l  ^  i'o>i'l)- 

4.     Construct  E  and  T. 

For  Merge  we  construct  0™  then  Op. 

TE  4.1     Construct  T. 

The  composition  operator  has  specification 

o~T:<b/z1>  =  Zq  such  that  TRUE 
where  aT:  U  X  LIST (]N)     -»    LIST(]N) 

The  primitive  operator  Cons  can  be  shown  to  satisfy  aT. 

TE  4.2     Construct  E 

TE  4.2.1     Derive  output  specifications  for  o-R. 

To  obtain  output  conditions  for  the     decomposition     operator     we     derive     a 
{xq,x ' q, a, XjyX1  ±] -precondition  of 

V«x0,x,0>,a/<xlfxl1»€  (LIST(]N)  X  LIST(]N))  X  3N  X  (LIST(IN)  X  LIST(]N)) 
V<Z0/b,z1>€LIST(IN)  XWX  LIST(W) 

[a  =  b  A  Ordered :x^  A  Ordered :x'^  A  Union:<Bag:x1,Bag:x,1>  =  Bagzz-,    A 
Orderedzz-^  A  Cons:<b,z1>  =  Zq    =^    Union:<Bag:xQ,Bag:x'Q>  =  Bag:zQ  A  Ordered :Zq], 

The  derivation  in  Figures  21a  and   21b  yields  the  precondition 

Ordered  rx-^  A  Ordered ix'^    =» 
ion:<Bag:xQ,Bag:x*Q>  =  Add:<a,Union:<Bag:x-,  ,Bag:x'  •,»  A  a<^Bag:x-,    A  a<_Bag:x*j. 


Un 


TE  4.2.2     Construct  E. 

The  decomposition  operator  o~E  has  specification 

oe:<Xq,x*q>  =  <a,<X2,x'2»  such  that  Ordered:xQ  A  Orderedtx'r,    =3> 
Orderedrx-^  A  Ordered  :x'j_  A  Length  X  Length :<Xq,x'q>  >2  Length  X  Length :<x1,x'1> 
A  Union:<Bag:xQ/Bag:x'0>  =  Add:<a/Union:<Bag:x1/Bag:x,1»  A  a^Bagix-^  A  ajCBagix'-^ 
where  aE:  LIST (]N)  X  LIST (U)     ->    H  X  (LIST(  ]N)  X  LIST(  ]N) )  . 
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Hypotheses:  1.  a=b 

2.  Ordered :x^ 

3.  Ordered :x* 2 

4.  Union:<Bag:x2,Bag:x'2>  =  Bag:z-^ 

5.  Ordered :z ^ 

6.  Cons:<b,z1>  =  z« 

Variables:      {xq,x' QrafX^,*' ±] 

Goal   1:  <Q1>     Union:  <Bag:xQf  Bag  :x  •  Q>  =  Bag  :zQ 

R5  +  h6 

<Q1>     Union:<Bag:xQfBag:x*Q>  =  Bag:  Cons  :<a,z-j> 

R5  +  L8 

<Q1>     Union  :<Bag:xQ,  Bag  :x'q>  = Add:<a,Bag:Zj> 

R5  +  h4 

<Q1>     Un ion :  <Bag : xQ , Bag : x  •  Q>  =  Add :  <a ,  Un ion :  <Bag :  x  ^ ,  Bag : x '  ■■ » 

P2 

where  01  is 

Ordered^  A  Ordered :x,1    =>    Union: <Bag:xQ, Bag :x*0>  =  Add  :<a,  Union  :<Bag:x1#  Bag  :x'i 

Figure  20a:     Deriving  output  specification  for  the  composition  operator  in  Merge 
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Goal    2: 


<Q3>     Ordered :z0 
R5  +  h6 
<Q3>     Ordered :Cons:<a,z1> 

R3  +  L12,   Rl 


<Q3>     a^BagrZj^ 

R5+h4 


<TRUE>     Ordered :z 


PI  +h5 


<Q3>     a  j<  Union^Bagix-^Bagix' p 

A  R3  +  B4 


<Q1>     a^BagtXj^ 
P2 


<Q2>     a^Bagix^ 
P2 


where  Ql  is  Ordered :x^  A  Ordered zx'^    =>   a_<Bag:xlf 

Q2  is  Ordered :x^  A  Ordered ix'^    =$a  <Baq:x' ±, 

and  Q3  is  Ordered :xj  A  Ordered :x' ±    =»    Ql  A  Q2 

Figure  20b:     Deriving  output  specification  for  the  composition  operator  in  Merge 


A  simple  conditional  program  called  Decompose  can  be  constructed  satisfying 
this  specification  with  derived   input  condition  XQ^nil   A  x'p^nil 


Decompose :<Xq,x'q>    —   if 


First:x0£ First :x'0    ->    <First:xQ,<Rest:x0,x,Q» 
First:xQ  ^First:x'0    ->    <First:x,0,<x0,Rest:xlQ» 


fi 


5.  Determine  the  guard. 

The  derived   input  condition  on  Decompose  is 

xQ^nil  A  x'0^nil 

thus  we  define  q:<xn,x*Q>  to  be  Xq  =  nil  V  x'n=nil.  We  can  easily  verify  that 
q  is  defined  for  all  pairs  of  input  lists. 

6.  Construct  the  primitive  operator. 


-79- 


We  create  the  specification 

h:<XQ,x'0>  =  Zq  such  that  Ordered :xQ  A  Ordered :x'0  A   (xQ=nil   V  x'0=nil)    =» 

Union: <Bag:x0, Bag :x' 0>  = Bag :Zq  A  Ordered:z0 
where  h: LIST (U)  X  LIST (U)     -»    LIST(]N). 

We  treat  the  disjunctive  input  condition  by  splitting  the  specification  into  two 

i 

cases : 

nO:<xO'x'o>  =  z0  sucn  t*iat  0rdere<3:xn  A  Ordered :x'0  A  xQ  =  nil    =» 

Union:<Bag:xQ/Bag:x,0>  =  Bag:zQ  A  Ordered:zQ 

where  hQ:LIST(]N)  XLIST(U)     -»    LIST(]N) 

and 

h'Q:<XQ,x'Q>  =  Zq  such  that  Ordered :xQ  A  Ordered :x'q  A  x'q  = nil    =» 

Union: <Bag:xQf Bag :x ' 0>  =    Bag:zQ  A  Ordered:z0 

where  h'0:LIST(]N)  X  LIST(]N)     -»    LIST  ( IN ) 

and  synthesizing  separate  programs  for  them.  The  selector  functions  2  and  1  are 
easily  shown  to  satisfy  hQ  and  h'0  respectively. 

7.  Create  new  input  conditions. 

This  step  is  skipped  since  operators  have  been  derived  which  satisfy  the 
specifications  h«  and  h*Q. 

8.  Assembly  of  a  divide  and  conquer  algorithm. 

Putting  together  the  operators  derived  above  we  obtain 


Merge :<Xq,x'q>    =   if 


Xq  =nil    -»   x'q 
x'q  =nil    -»  Xq 


XQ^nil   A  x'0^nil    -»   Cons*  (Id  X  Merge)  •Decompose  :<Xq,x'q> 
fi 

The  derived   input  condition  for  Merge  is  TRUE.     The  complete  Merge  sort     program 


-80- 


Msort:x    —   if 

Length :x  <  1    -»    x    D 

Length:x  >   1    -»   Merge* (Msort X  Msort) -Listsplit:x 
fi 

Merge: <xlfX2>    —   if 

Xj^  =nil    -»    x2    D 
x2  =  nil    ->    x±    D 

x-^nil   Ax2^nil    -»   Cons-  (id  X  Merge)  -Decompose :<x1,x2> 
fi 

Decompose :<x ^ /X2>    ■■   if 

First:x2j<First:x2    -»    <First:x1,<Rest:xpX2»    0 
Firsttx^  >^First:x2    -»    <First:x2, <xlfRest:x2» 
fi 

Figure  21:  Complete  Merge  Sort  Algorithm. 


4.3  Synthesis  of  <a  Quick  Sort  Algorithm 

4.3.1  Synthesis  of  Qsort 

The  synthesis  of  a  quicksort  proceeds  as  with  Mergesort  diverging     only     at 
step  4. 

1,2/3.     Determine  a  sort  set,  signature,  component  problems,  and  a     well-founded 
ordering. 

As  in  Mergesort  let 

S={§}, 

£  be  a  simple  S-sorted  signature  of  type   {§§,§}, 

E    =LIST(]N), 

T    =LIST(]N), 


J  :x   4=¥  TRUE,  and 
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P  :<x,z>   <£=»  Bag:x=Bag:z  A  Ordered:z. 
Define  Xq^x^  iff  Length:xQ  >  Lengthtx-^. 

4.     Construct  decomposition  and  composition  operators. 

In  Msort  we  chose  a  simple  decomposition  operator,   in     Qsort     we     choose     a 
simple  composition  operator. 

TE  4.1     Construct  T. 

The  composition  operator  has  partial  specification 

aT:<z1,Z2>  =  Zq  such  that  TRUE 
where  crT:  LIST  (IN)  X  LIST  (U)     -»    LIST(]N). 

The  operator  Append  satisfies  aT  with  derived   input  condition  TRUE. 

TE  4.2     Construct  E. 

TE  4.2.1     Derive  output  conditions  for  a£. 
We  seek  a   {xQ,xlfx2}-precondition  of 

V<x0,x1/x2>6LIST(]N)  X  LIST(]N)  X  LIST(]N) 

V<Z0,ZlrZ2>€LIST(]N)  XLIST(]N)  XLIST(]N) 

[Bag:x^  =  Bagtz^       A       Ordered  :z^       A       Bag:x2  =  Bag:z2       A         Ordered  :z2         A 

Append : <z^,z2>  =  Zq    =3>    Bag:xQ  =  Bag:zQ  A  Ordered :Zq] 

and  in  Figure  22  we  derive 

Bag:x^_<  Bag:x2  A  Bag:xn  =  Union:<Bag:xlfBag:x2>. 


TE  4.2.2  Construct  aE. 

Using  previously  derived  results  we  construct  by  instantiation  the  specifi- 
cation 

aE:x0  =  <x,  /X2>  such  that  Length:x0  >  Lengthtx-.    A  Length:x0  >  Length:x2  A 

Bagtx^  j<  Bag:x2  ^  Ba9:xn  =  Un^on:<Ba9:xi'Ba^;x2> 
where  aE:  LIST (U)     -»    LIST(  ]N)  X  LIST(  M) . 
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Hypotheses:     hi.     Bagrx^  =  Bag:z^ 
h2.     Ordered  :z-, 
h3.      Bag:x2  =  Bag:z2 
h4.     Ordered:z2 
h5.     Append :  <zlfz2>  =  Zq 

Variables:      {xQ/X-^x-p} 


Goal   1: 


<Q1>     Bag:xQ  =Bag:zQ 
R5+h5 
<Q1>     Bag:xQ  = Bag: Append :<zlfz2> 
R5  +  L9 
<Q1>     Bag:xQ  =  Union:<Bag:z1/Bag:z2> 

R5  +  hl,   R5  +  h3 
<Q1>     Bag:xQ  =  Union :<Bag:x^, Bag: x2> 
P2 
where  Ql  is  Bag :Xq  =  Union: <Bag:x-,, Bag :x2> 


Goal   2: 


<Q2>     Ordered :z0 
R5+h5 
<Q2>     Ordered: Append :<zlfz2> 


R3  +  L13,   Rl,   Rl 


<TRUE>     Ordered :Zj       <Q2>     Bagrzj  <  Bag:z2         <TRUE>     Ordered :z2 


R5  +  hl,   R5+h3 


PI  +h2 

<Q2>     Bag:x1£Bag:x2 
P2 
where  Q2  is     Bag:x^  jCBag:x2 


PI  +h4 


Figure  22:     Derivation  of  output  conditions  for  the  decomposition  operator  of  Qsort 


This  is  an  incomplete  specification  for  the  well-known  partitioning  operator  of 
a  quicksort.  In  the  following  section  we  synthesize  an  operator  called  Part 
satisfying  this  specification  with  derived   input  condition  Length:x0>l. 


5.     Determine  the  guard. 
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The  guard  ~q:xQ  is  simply  the  derived  input  condition  on  crE  so  ~q:xQ  <=> 
Length:xQ  >  1  and  q:xQ  «=»  Length:x0£  1.  It  is  easily  verified  that  q  is 
defined  on  all  legal   inputs. 

6.  Construct  the  primitive  operator. 

We  construct  specification 

n:x0  =  z0  sucn  that  Length  :xQ£l    =»    Bag:xQ  = Bag:zQ  A  Ordered :Zq 
where  h:LIST(]N)     -»    LIST(]N) 

and  can  easily  show  that  Id  satisfies  it. 

7.  Derive  a  new  input  condition. 

Since  Id  satisfies  specification  h  this  step  is  bypassed. 

8.  Assemble  divide  and  conquer  algorithm. 

The  operators  constructed  above  compose  to  form  the  following  program: 

Qsortrx    a   if 

Length:x£l    ->   x   0 

Length :x  >  1    ->   Append*  (Qsort  X  Qsort)  'Part :x 
fi 

The  derived  input  condition  on  Qsort  is  TRUE. 

4. 3. 3  Synthesis  of  Partition 

In  the  previous  section  we  derived  the  specification 

Part:xQ  =  <x^,X2>  such  that  LengthrxQ  >  Lengthrx^  A  LengthrxQ  >  Lengthy  A 

Bagrxj  <^Bag:x2  A  Bag  :xn  =  Union  :<Bag:xj_,  Bag  :x2> 

where  Part: LIST (U)     -»    LIST(]N)  X  LIST(]N) . 

This  specification  can  be  transformed  to     a     somewhat     simpler     form     using     the 
equivalence 

wllw2  ^*    3i[Wi£i  A  i<.w2^ 
where  w,  and  w2  are  variables  over  BAGS(]N)   and  i  varies  over    ]N.     Thus  we  get 
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Partl:x0  =  <x1,x2>  such  that  3i[Bag:x2_<i   A  i_<Bag:x2]    A 

Bag :xq  =  Union: <Bag:xlfBag:x2>  A  Length:xQ  >  Lengthy  A  Length:xQ  >  Length:x2 

where  Parti: LIST(  IN)     -»    LIST(  TN)  X  LIST(  ]N)  . 

We  can  further  transform  this  to 

Part2:xQ  =  <b,<z1,z2»  such  that  Bagrz^b  A  b<^Bag:z2  A 

Bag:xQ  =  Union :<Bag:z-^ f Bag: z2>  A  Length :xQ>Length:z1  A  Length  :x0>Length:z2 

where  Part2:  LIST  (IN)     ->    IN  X  (LIST(  H)  X  LIST(]N) ) 

Noting  that  2*Part2:x0  satisfies  the  specification  for  Part  we  now  synthesize     a 
divide  and  conquer  algorithm  for  Part2. 

1.  Determine  a  sort  set  and  signature. 

We  choose  LIST(IN)  as  recurrent  type  on  the  input  and  output  domains  and 
select  the  algebra  A  =  <{  ]N , LIST ( ]N ) } ,  {Cons}>  to  give  us  the  sort  set  S  =  {c,§} 
and  signature  £  of  type  <c§,§>. 

2.  Determine  the  component  problems. 

As  in  the  synthesis  of  Select,   Insert,  and  Merge  let 
E    =LIST(IN) 

T    =  *I  X  (LIST (IN)  XLIST(IN)) 

J   :x    <=»   TRUE 

P  :<XQ/<b/<z1,z2>»   <=» 

Bagrz^b  A  b<^Bag:z2  A 

Bag:xn  =  Union  :<Bag:Zp  Bag  :z2>  A 

Length :xQ>Length:z1  A  Length :x0>Length:z2. 

Ec  =  ]N ,  and 

TC=3N. 

We  seek  a  function  fs  which  maps  Ec  to  TQ  and  find  Id,  so 

Jc:x  4=*>  TRUE 
Pc:<x,z>  4=»  x  =  z. 


3.     Determine  a  well-founded  order inq  on  E  , 
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Again  define  Xq^-Xj  by  Length:x0  >  Length :x±. 
4.     Construct  E  then  T. 

ET  4.1     Construct  E. 

We  construct  a  simple  decomposition  operator  according     to     the     incomplete 
specification 

aE:x0  =  <a'xl>  sucn  tnat  Length:xQ  >  Lengthtx-^ 
where  crE: LIST (]N)     ->    ]N  X  LIST(]N) . 

In  the  synthesis  of  Select     we     showed     that     [First, Rest]     satisfies     the     same 
specification  with  derived   input  condition  Xg^nil. 

ET  4.2     Construct  T. 

ET  4.2.1     Derive  output  conditions  for  Op. 

The  composition  operator's     output     conditions     are     found     by    deriving     a 
{bfCjyZ-jyZ'pCQfZQ,  z'q} -precondition  of 

V<c0,<z0,z'0»€  KX  (LIST(W)  XLIST(W)) 

V<b,<c1,<z1/z'1>»€  H  X  (N  X  (LIST(W)  X  LIST(]N))) 

V<x0,a/x1>6LIST(]N)  X  LIST3N  XLIST(W) 

[    [FirstfRest]  :Xq  =  <a,x1>  A  Bagrz^c-j^  A  c-^Bagtz'^  A 

Bag  :x^  =  Union:  <Bag:z,,  Bag  :z'^>     A     Lengthzx^     >     Length:z,        A       Length:x^       > 

Lengthtz'i  A  a  =  b 

=»    Bag:zQ_<CQ  A  CQ^Bagrz'Q  A  Bag:xQ  =  Union:<Bag:zQfBag:z,0>  A 

Length:xg  >  Length:zQ  A  Length:xQ  >  Length :z'q]. 

In  Figures  24a  and   24b  we  derive  the  precondition 

Bag:z-i<c-,    A  c,  _<  Bag:z*  •,    =»    1  +  Lengthcz-,  +  Length:z' -,>Length:z0  A 

1  +  Length :z-^  +  Length:z,1>Length:zl0  A 

Add:<bfUnion:<Bag:zlrBag:z'1»  =  Union:<Bag:zQ,Bag:z'Q>  A 

Bag:ZQ<_cn  A  cQ_<Bag:zQ. 

ET  4.2.2     Construct  T. 
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Hypotheses:   1.  [First, Rest] :xQ  =  <a/x1> 

2.  Baq:z^<_c^ 

3.  c-j^^Bagtz^ 

4.  Bag  :Xi  =  Union:  <Bag  :z,,  Bag  :z',> 

5.  Lengthy  >  Lengthy 

6.  Lengthtx^  >  Lengthcz'-^ 

7.  a  =b 

Variables:      {bfC^z^z'  ifCo'zO'z'o* 

Goal    1:  <Q1>     Bag:xQ  =  Union :<Bag:zQ, Bag: z'0> 

R6  +  L7  +  hl 

<Q1>  Bag:Cons:<a,x1>  =  Union:<Bag:z0,Bag:z'0> 

R5  +  L8 

<Q1>  Add:<a,Bag:x1>  =  Union:<Bag:z0,Bag:z'Q> 

R5  +  h4 

<Q1>     Add:<bfUnion:<Bag:z1,Bag:z,1»  =  Union :<Bag:zQ, Bag :z'0> 

P2 

where  Ql  is 
Bag^j^c^  Ac^^Bag^'-j^    =»   Add:<bfUnion:<Bag:z1,Bag:z'1»  =  Union :<Bag:zQ/ Bag :z'Q> 


Goal    2: 


<Q2>     Bag:zQ_<c0 
P2 
where  Q2  is  Bag^^c-^  A  c^  ^Bagtz'^    =>    Bag:z0£c0 


Goal   3:  <Q3>     c0<Bag:z'0 

P2 
where  Q3  is  Bagtz^jCc^  A  c^Bagiz'^    =»   cQ  <^Bag:z'0 

Figure  23a:   Deriving  output  conditions  for  the  decomposition  operator  in  Part2. 


The  specification  for  the  composition  operator  o~T  is 
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crT:<b,<c1,<z1,z,1>»  =  <c0,<z0,z'0»  such  that  Bag^^C],    A  c-^KBaqiz'-^ 

=»    ( Add :  <b,  Union  :<Bag:Zp  Bag  :z2»  =  Union:<Bag:z0,Bag:zl0>  A 

1  +  Length :z^  +  Length :z,1>Length:zQ  A 

1  +  Length:z-^  +  Length:z'1>Length:zQ  A 

Bag:zQ<c0  A  cQ  <Bag:zQ 

where  aT:]N  X  (IN  X  (LIST (U)  X  LIST (U)))     ->    IN  X  (LIST(U)  X    LIST(]N)) 

A  simple  conditional  program  can  be  derived  satisfying  this     specification     with 
derived  input  condition  TRUE: 


Goal   4:  <Q4>     Length:xn  >  Length:zQ 

R6  +  L7+hl 
<Q4>     Length :Cons:<a,X2>  >  Length :zQ 

R5  +  L15 
<Q4>     l+Lengthtx^  >  Length:z0 

R6  +  L19+h4 
<Q4>     1 +Card:  (Union:<Bag:z1,Bag:z,1>)    >  Length :zn 

R5  +  B5 
<Q4>     1  +  Card tBagiz-j^  +  Card tBagiz'-j^  >  Length:zn 

R5  +  L18 
<Q4>     1  +  Lengthy  +  Length: z'^  >  Length:zQ 

P2 
where  Q4  is  Bag:z-|,  _<  c^  A  c^_<Bag:z'^    =»    1  +  Length :z^  +  Length :z',    >  Length:zn 

Goal   5:  <Q5>     Length :xQ  >  Length :z'0 

(Derivation  similar  to  the  derivation  of  Goal  4) 
where  Q5  is  Bagtz^c-^  A  c^KBaqiz*  -^    =»    1  +  Lengthy  +  Length :z'i  >  Lengthtz'Q 

Figure  23b:   Deriving  output  conditions  for  the  decomposition  operator  in  Part2. 
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Compose  :<b,<c,<z,z'»>    ■   if 

b<c    -»    <c,Cons:<b,z>,z'>    0 
b^>c    ->    <c,z,Cons:<b,z'» 
fi. 

5.  Determine  the  guard. 

We  take  as  ~q  the  derived  input  condition  x  ^  nil  of  aE/  thus  q:x  4=» 
x  =nil.  It  is  easily  shown  that  q  is  defined  on  all  legal  inputs. 

6.  Construct  the  primitive  operator. 

We  construct  the  specification 

h:x  =  <c,<z,z'»  such  that  x  =  nil    =»    Bag:z<c  A  c<Bag:z'    A 

Bag:x  =  Union: <Bag:z, Bag :z'>  A  Length:x  >  Length:z^  A  Lengthrx  >  Lengthtz'-^ 

where  h: LIST (]N)     -»    LIST(  IN)  X  LIST(  ]N)  . 

As  in  the  synthesis  of  Select  we  can  show  that  this  specification  is     unsatisfi- 
able. 

7.  Derive  a  new  input  condition. 

We  form  a  new  input  condition    (because  of  the  unsatisfiablility     of     h)     by 
simplifying 

(TRUE   A  xQ^nil)    V    (TRUE   A  x  =  nil    A  FALSE) 

to  xQ^nil.     We  let  J  :xQ   <£=»  xfi  ^  nil  and  return  to  step  4  in  order  to  redo     the 
synthesis. 


4'     Construct  E  and  T. 

ET  4.1'     Construct  E. 

The  new  specification  for  o"E  is 

oE:x0  =  <a/x1>  such  that  xQ  ^  nil    =^    (x-^nil   A  Length :xQ>Length:x ±) 
where  crE: LIST (U)     ->    ]NXLIST(]N). 

Since  the  operator    [First, Rest]   satisfied  the     first     specification     for     crR     it 
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seems     reasonable     to     try     it    again.       Proposition     4     is     used     to     show  that 
[First, Rest]   satisfies  o*E  with  derived  input  condition  Rest:x^nil. 

ET  4.2'     Construct  T. 

This  step  is  not  affected  by  the  introduction  of  a  new  input  condition  thus 
our  previous  synthesis  of  Compose  can  be  used. 

5'.     Determine  the  guards. 

This  time  the  derived   input  condition  on  ov.  is  Resttx^nil  so 
~q:x   <=»  Rest:x^nil  and  q:x   4=»  Rest:x=nil. 
It  is  easily  verified  that  q  is  defined  on  all  legal  inputs. 

6'.     Construct  the  primitive  operator. 

The  primitive  operator  has  specification 

h:x  =  <c,<z,z*»  such  that  Rest:x  =  nil    =»   Bagrz^c  A  c£Bag:z'    A 

Bagrx  =  Union:<Bag:z,Bag:z'>  A  Length:x  >  Lengthrz  A  Length:x  >  Lengthtz' 

where  h: LIST (H)     -»    IN  X  (LIST (]N  X  LIST (  U) ) 

and  again  we  find  this  to  be  unsatisfiable.     Thus  we  will  need     to     find     a     new 
input  condition  and  return  to  step  4. 

7'.     Derive  a  new  input  condition. 

The  new  input  condition  is  found  by  simplifying 

(x^nil   A  Restrx^nil)    V   (x^nil   A  Rest:x=nil   A  FALSE) 

to  Length :x  >  1.     We  return  again  to  step  4,   letting  J  :x  be  Length :x  >  1. 

4 • ' .     Construct  E  and  T. 

ET  4.1".     Construct  E. 

The  new  specification  for  aE  is 
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<je:Xq  =  <a/x1>  such  that  Length:xQ  >  1    =>    (Lengthy  >  1   A  Length:xQ  >  Lengthy) 

where  <te: LIST (]N)     ->    LIST(  IN)  X  LIST(  IN) . 

As  in  step  ET  4.1'  we  use  Proposition  4  to     match     [First,     Rest]     with     crE     and 
obtain  derived   input  condition  Length :xQ  >  2. 


This  step  is  the  same  as  ET  4.2  since  the  change  in     input     condition     does 
not  affect  the  synthesis  of  crT. 

5'*.     Determine  the  guards. 

The  derived   input  condition  on  o~E  is  Length :Xq  >  2  so 

~q:x   <=»   Lengthrx  >  2  and  q:x   <=*>   Length:x_<  2. 
Again  we  easily  check  that  q  is  defined  on  all  legal   inputs. 

6''.  Construct  the  primitive  operator. 

The  primitive  operator  has  specification 

h:x  =  <c,<z,z'»  such  that  Rest:x^nil   A  Length:x_<2    =»    Bag:z<c  A 
c£Bag:z'    A  Bag:x  =  Union :<Bag:z,Bag :z'>   A  Length:x  >  Length:z  A  Length:x  >  Length:z' 
where  h: LIST (]N)     -»    IN  X  LIST(  IN)  X  LIST(  ]N) ) . 

A  simple  conditional  program  can  be  shown  to  satisfy  this  specification: 

h:x    =   if 

First:x£  First 'Rest:  x    -»    <First:xf  Cons:<First:x,nil>,   Rest:x>    fl 
First :x  >^First*Rest:x    ->    <First*Rest:x/   Rest:xf  Cons:<First:x/nil» 
fi. 

7".     Derive  a  new  input  condition. 

Since  an  operator  was  constructed  which  satisfies  the  specification     for     h 
we  can  bypass  this  step. 

81'.     Assembly  of  the  divide  and  conquer  program. 

Putting  together  all  of  the  operators  derived  above  we  obtain 
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Part:x    s   2*Part2:x 

Part2:x    -   if 

Length  :x_<  2    -»    h:x    0 

Length:x  >  2    -»   Compose*  (Id  X  Part2)  *  [First ,Rest]  :x 
fi. 

Length:x>l  is  the  derived  input  condition  on  Part2.     The  complete  Quicksort  pro- 


Qsort:x    —   if 

Length:x_<l    ->    x    Q 

Length :x  >  1    -»  Append* (Qsort X  Qsort) • Part :x 
fi 

Part:x    =   2*Part2:x 

Part2:x    =   if 

Length:x_<2    ->    h:x    D 

Length:x  >  2    ->   Compose*  (Id  X  Part2)  *  [First, Rest]  :x 
fi 

h:x    —   if 

First:x_<  First 'Rest:  x    -»    <First:x,  Cons:<First:x,nil>,   Rest:x>    D 
First:x^>  First*Rest:x    -»    <Firsf  Rest:x,  Rest:x,  Cons:<First:x,nil» 
fi 

Compose:<a/<b/z1,z2»    —   if 

a£b    -»    <b,  Cons:<a,z<j>,   z2>    D 
a_>b    -»    <b,   Zi,  Cons:<a,z2» 
fi 


Figure  24:  Complete  Quicksort  Program 
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gram  is  listed  in  Figure  24. 

4.4  Other  Sorting  Algorithms. 

The  sorting  problem  admits  a  variety  of  solutions.  We  have  detailed  the 
synthesis  of  four  -  a  selection  sort,  insertion  sort,  mergesort,  and  quicksort. 
In  this  section  we  briefly  indicate  how  some  of  the  other  kinds  of  sorting  algo- 
rithms could  be  synthezised  by  our  method.  The  exercise  of  deriving  several 
sorting  algorithms  from  a  single  specification  has  also  been  reported  in 
[6,7,10]. 

Bubble  Sort  and  Sinking  Sort  [13] 

Bubble  sort  can  be  viewed  as  a  variation  on  selection  sort  in  which  the 
Select  operation  is  performed  by  scanning  through  the  input  list  interchanging 
consecutive  elements  which  are  out  of  order.  The  result  is  that  the  smallest 
element  is  deposited  at  one  end  of  the  list.  The  smallest  element  and  the  rest 
of  the  list  are  then  easily  obtained.  The  scan  and  interchange  process  is  an 
instance  of  the  general  programming  technique  known  as  local  search.  Local 
search  produces  an  output  object  by  a  sequence  of  small  local  modifications 
applied  to  an  input  object.  In  the  Bubble/Selection  operator  the  local  modifi- 
cations are  the  interchanges  of  consecutive  elements  which  are  out  of  order. 
Thus  to  synthesize  a  bubblesort  we  would  proceed  as  with  Ssort  except  that  we 
would  construct  a  local  search  algorithm  for  Select  rather  than  a  simple  divide 
and  conquer  algorithm. 

Similarly,  sinking  sorts  may  be  viewed  as  variations  on  insertion  sorts  in 
which  the  specification  for  Insert  has  been  satisfied  by  a  local  search  algo- 
rithm. 

Heap  Sort  [13] 

The  essence  of  heapsort  is  the  heap  data  structure  which  allows  fast  opera- 
tors for  insertion  of  arbitrary  elements  and  selection  of  the  smallest  element 
on  the  heap.  In  a  sense  heapsort  is  like  a  selection  sort  in  that  it  repeatedly 
obtains  the  smallest  remaining  element  on  the  heap  and  adds  it  to  the  output, 
neap  sort  is  a  classic  instance  of  a  greedy  algorithm  [1].  Thus,  a  design 
theory  for  simple  greedy  algorithms  would  enable  the  synthesis  of  heapsort. 
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5.  Conclusion 

In  this  paper  we  have  presented  a  framework  for  a  top-down  program  syn- 
thesis system.  The  future  success  of  systems  of  this  kind  depend  on  the 
development  of  design  methods  covering  many  classes  of  useful  algorithms.  We 
have  taken  a  first  step  in  that  direction  with  design  methods  for  simple  divide 
and  conquer  algorithms  and  simple  conditional  programs.  We  are  currently  imple- 
menting a  system  which  includes  these  design  methods. 

The  main  distinguishing  feature  of  our  approach  is  the  ability  to  decompose 
a  problem  into  subproblems,  each  described  by  an  automatically  derived  specifi- 
cation. This  ability  depends  on  knowledge  of  the  structure  of  divide  and  con- 
quer algorithms  (formulated  in  Theorem  1)  and  an  engine  for  deriving  precondi- 
tions. The  need  to  precisely  express  the  structure  of  divide  and  conquer  algo- 
rithms has  led  to  the  notions  of  decomposition  algebras,  homomorphisms  from 
decomposition  algebras  to  composition  algebras,  and  finally,  the  expression  of 
the  divide  and  conquer  principle  as  a  computational  homomorphism.  We  are 
currently  using  these  tools  in  exploring  the  structure  of  other  classes  of  algo- 
rithms. A  precondition  engine  is  being  implemented  and  currently  can  handle 
most  of  the  derivations  in  this  paper.  We  feel  that  the  precondition  problem 
will  eventually  take  on  a  wider  significance  than  its  role  in  our  system.  Many 
of  the  tasks  faced  by  computer  science  and  AI  may  be  usefully  formulated  in 
terms  of  theorem  proving  in  a  first-order  logic.  See  for  examples  [9].  The 
greater  flexibility  and  power  of  preconditions  should  enable  us  to  greatly 
extend  the  set  of  tasks  which  can  be  precisely  expressed  and  handled  by  deduc- 
tive means. 

Another  distinguishing  feature  of  our  approach  is  the  correct  handling  of 
incomplete  specifications.  A  user  can  even  omit  input  conditions  knowing  that 
(at  a  cost!)  the  system  can  derive  input  conditions  for  its  product.  As  a 
result  specifications  are  somewhat  easier  to  create.  Another  advantage  of 
incomplete  specifications  is  that  it  makes  it  easier  for  the  system  to  create 
specifications  for  subproblems. 
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Appendix 

We  list  below  the  data  structure  knowledge  required  by  the  examples  of  this 
paper.  It  is  grouped  according  to  data  types  and  includes  operator  signatures, 
typical  composition  algebras,  and  known  theorems.  All  variables  are  implicitly 
universally  quantified. 

1.  Natural  Numbers    (]N) 

Known  Functions: 

+:  U  X  3N     -»    H 

<,<,=,  ?  ,  >  ,>:NX  N     -»     B 

Id :  ]N     -»    IN 

Known  Theorems  -  let  i,  j,  k  vary  over    H 
nl.   i>0  4*  i  +  j  >  j 
n2.   i  +  i  >j    =>    i  >   (j  div  2) 

2.  Lists  of  Natural  Numbers   (LIST(]N)) 

Known  Functions: 

First:LIST(]N)     -»    ]N  + 

Rest:LIST(]N)     -»    LIST(U)  + 

Cons:lN  XLIST(]N)     -»    LIST(]N) 

[Fi  rs  t,  Rest  ]:  LIST  (M)     -»    H  +  X  LIST(  IN)  + 

Listsplit:LIST(]N)     -»    LIST ( ]N )  X  LIST (3N) 

Append :  LIST  ( ]N )  X  LIST  (]N)     -»    LIST(]N) 

Id:LIST(]N)     -»    LIST(]N) 

Length:  LIST  (U)     -»    ]N 

Ordered :  LIST  (W)     -»    B 

Bag:LIST(lN)     -»    BAGS(]N) 

Algebras:  <{LIST(]N) ,  N}#  {Cons}> 
<{  LIST  (M)},{  Append  }> 
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Known  Theorems:  let  x,  y,  z  vary  over  LIST(]N),  i  vary  over  Tti ,     and  w 
vary  over  BAGS  (IN) 

LI.  Defined :x 

L2.  x=x 

L3.   Defined  :x  A  Defined  :y  4=>  Defined :  (x  =  y) 

L4.  x^nil    4=^  Defined -First  :x 

L5.   x^nil    <=>  Defined* Rest :x 

L6.  x^nil    4=»  Defined:  [First, Rest]  :x 

L7.    [First, Rest]  :x  =  <a,y>     4=*>     Cons:<a,y>=x 

L8.   Bag* Cons :<a,x>  =  Add:<a,Bag:x> 

L9.   Bag 'Append  :<XpX2>  =  Union:<Bag:x-L,Bag:x2> 

L10.    Defined *Listsplit:x 

Lll.   Ordered :nil 

LI 2.  a  <^Bag:x  A  Ordered :x   4=£>  Ordered* Cons :<a,x> 

L13.   Ordered  :x^  A  Ordered  :X2  A  xi<.x2   ^  Ordered  'Append  :<x-wX2> 

L14.    Length:nil  =  0 

L15.    1  +  Length :x  =  Length *Cons:<a,x> 

L16.   x  ?*  nil    =*>    1  +  Length* Rest :x  =  Length :x 

L17.   Length:x^  +  Length:x2  =  Length  'Append  :<x-,  ,x2> 

L18.   Card 'Bag  :x  =  Length :x 

L19.   Bag:x=w    =»    Length :x  =  Card:w 

L20.   Bag:nil  =  0 

3.  Bags  of  Natural  Numbers  (BAGS(]N)) 

Known  Functions: 

Add :  IN  X  BAGS  ( IN )  -»  BAGS  ( IN ) 

Un ion : BAGS ( ]N )  X  BAGS (]N)  -»  BAGS(]N) 

<  :H  XBAGS(]N)  -»  B 

<  :BAGS  ( IN )  X  BAGS  ( ]N )     -»    E 
Card:BAGS(IN)     -»    ]N 

Algebras:      < {BAGS ( U ),  K] ,  {Add} > 
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Known  Theorems:  let  w  vary  over  BAGS(]N)  and  i  vary  over  ]N 

Bl.  w  =  w 

B2.  i  <    0 

B3.  i^^i2  A  ii<.w  <=*>   i^  <.Add:<i2/W> 

B4.  i_<w-^  A  i<.w2   ^    i  _<  Union :<w-,,w2> 

B5.  Card 'Union:  <wlfw2>  =  Card:w^  +  Card:w2 

B6.  Card  •  Add :  <a , w>  =  1 +Card:w 
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